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I. 


INTRODUCTION 


1 .  PURPOSE 

This  technical  report  documents  systems  engineering  and  analysis 
in  support  of  the  Defense  Communications  System  (DCS)  Plan  FY  80/90. 

Its  principal  purposes  are:  to  identify  and  analyze  technically 
oriented  issues  and  problems  of  interest  to  Defense  Communications 
Agency  (DCA)  engineers,  to  assess  the  system  impact  of  alternative 
solutions  to  the  interface  and  integration  issues,  to  assess  cost 
and  performance  impacts,  to  identify  specific  areas  for  further 
in-house  addressal  or  contractor  support,  and  to  identify  specific 
areas  for  MIlDEP  support. 

This  document  is  expected  to  provide  management  with  technical 
analyses  necessary  to  select  subsystem  directions  in  areas  of  emphasis 
that  will  evolve  from  the  current  DCS  configuration  to  an  architecture 
capable  of  satisfying  future  DCS  requirements.  — ; 

2.  RELATIONSHIP  TO  DCS  PLANNING  DOCUMENTATION 

This  document  and  two  other  related  technical  reports  provide 
technical  support  for  the  DCS  Plan  FY  80/90.  The  others  are  TR  1-77, 
"Planning  and  Programming  Transition  Issues",  and  TR  3-77,  "Operational 
and  Maintenance  Manning  Reduction  Studies".  TR  1-77  addresses  those 
management-oriented  system  design  issues  and  the  archi tectural 
alternatives  available  for  determining  major  program  directions  and 
relative  emphasis.  TR  3-77  addresses  both  near-term  and  long-term 
methods  of  reducing  military  manning  requirements  for  DCS  facilities, 
particularly  in  the  overseas  regions.  Together,  these  three  reports 
provide  the  technical  investigations  and  analyses  to  support  the  DCS 
Plan  FY  80/90. 

The  DCS  Plan  provides  the  significant  system  design  issues, 
objectives,  alternatives,  and  selected  course  of  action  for  further 
development  and  ultimate  implementation.  Specific  implementation 
actions  and  detailed  project  developments  necessary  to  field  and 
support  a  worldwide  telecommunications  system  are  contained  in  the 
DCS  Five-Year  plans  (FYP),  Subsystem/Project  Plans  (S/PP),  major 
program  management  plans,  and  similar  documents.  An  interaction 
between  the  DCS  Plan  and  the  existing  programming  and  implementation 
documents,  including  those  being  developed,  is  required  in  order  to 
effect  any  major  modifications  to  current  programs. 


1-1 


3.  SCOPE 


The  scope  of  the  document  is  defined  by  the  specific  system  issues 
designated  to  receive  continuing  system  design  and  engineering  attention. 
They  are  discussed  in  the  following  paragraphs. 

For  the  subsystems  and  elements  which  characterize  the  DCS,  certain 
information  about  the  health  and  disposition  of  the  system  is  required. 
This  information  must  originate  with  and  be  exchanged  by  the  various 
subsystems  and  elements.  The  questions  that  must  be  addressed  for  these 
actions  are  specifically  what  information  is  required,  for  what 
purpose  is  it  needed  (importance  and  timeliness),  to  whom  must  it 
be  transmitted,  and  how  will  the  transmittal  be  accomplished?  All 
of  these  questions  are  particularly  important  relative  to  the  efficient 
maintenance,  operation,  management  and  control  of  the  DCS.  An 
assessment  of  all  of  these  questions,  except  the  last,  has  been  made 
and  detailed  examples  are  presented. 

DCS  plans  specifically  address  both  transmission  and  switching 
subsystems.  Certain  incompatibilities  in  the  detailed  specifications 
of  the  transmission  and  switching  equipment  cause  a  system  interface 
problem.  Three  conceptual  solutions  are  proposed  and  various 
alternatives  are  analyzed  to  determine  the  strengths  and  weaknesses 
of  each. 

The  transition  of  the  DCS  towards  an  all-digital  communications 
system  raises  the  question  of  how  this  digitization  is  to  be  accom¬ 
plished.  The  current  64  kb/s  PCM  strategy  is  bandwidth  inefficient 
compared  to  a  lower  rate  delta  modulation  (DM)  alternative.  Channel 
capacity  and  spectrum  allocation  problems  may  force  the  use  of  a 
lower  rate  DM  strategy.  Such  a  strategy  is  analyzed  and  compared  to 
the  current  PCM  approach. 

The  DCS  secure  voice  population  is  composed  of  isolated 
subscribers,  small  bodies  of  subscribers,  and  large  communities  of 
subscribers.  These  classes  give  rise  to  certain  alternatives  for 
interfacing  them  with  the  DCS  backbone  network.  Alternatives  to 
perform  this  action,  ranging  from  individual  secure  terminals, 
bulk  encryption,  and  PBX-to-PBX  security  are  developed  and  tradeoffs 
are  performed. 

Major  costs  for  any  system  that  requires  both  hardware  and 
software  packages  are  incurred  in  the  definition,  design,  development, 
and  testing  of  the  software.  The  significance  of  this  system  issue 
is  addressed  and  potential  areas  for  greatest  savings  are  discussed. 
Approaches  to  software  design  are  developed  and  the  programming  language 
issue  is  detailed.  An  approach  for  the  reduction  of  software  costs 
is  given. 
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The  DCS,  as  a  system,  is  characterized  by  periodic  transients 
resulting  from  actions  taken  to  overcome  equipment  failures.  These 
transients  can  cause  instability  within  the  system.  This  instability 
can  be  viewed,  for  example,  in  terms  of  fault  propagation  in  that 
an  equipment  failure  may  cause  other  equipments  to  fail,  or  may 
result  in  unnecessary  maintenance  activity  to  parts  of  the  system 
that  are  functioning  within  normal  tolerances.  This  issue  is  addressed 
in  the  context  of  the  effect  of  timing  and  synchronization  and  signal 
encryption  on  system  stability,  and  the  fault  modes  that  can  occur 
which  influence  system  stability. 

These  major  issues  are  addressed  as  if  they  were  self-contained. 
However,  as  can  be  inferred  from  the  issue  discussions,  they  are 
indeed  connected  and  some  of  the  discussions  pervade  several  of  the 
issues.  This  is  intended.  It  is  also  intended  that  the  addressal  of 
the  issue  alternatives  will  provide  a  clearer  picture  of  the  system 
architecture  and  the  options  available  to  management. 

4.  ASSUMPTIONS,  CONSTRAINTS,  AND  APPROACH 

In  the  development  of  this  report,  current  DCS  plans  and  programs 
were  considered.  These  were  the  foundation  and  constraints  from 
which  issues  were  defined  and  developed,  and  from  which  alternative 
solutions  were  advanced.  The  structure  of  the  architecture  for 
existing  DCS  programs,  for  a  given  issue  area,  provided  the  basis 
from  which  to  begin.  All  assumptions  and  constraints  for  each  issue 
are  stated. 

The  approach  taken  in  this  report  is  to  show  what  capabilities 
exist,  those  that  can  be  achieved,  and  what  benefits  can  be  gained. 


1-3 


p 


II.  SUBSYSTEM  INTERFACES 


I.  INFORMATION  EXCHANGE  AMONG  MAJOR  DCS  SUBSYSTEMS  AND  ELEMENTS 

Circa  1980-1982,  the  Defense  Communications  System  will  be  a 
hybrid  consisting  of  subsystems  which  are  both  analog  and  digital 
in  nature.  The  newer  digital  elements  will  be  introduced  via  major 
DCS  programs  such  as: 

•  Digital  European  Backbone,  Phase  I  through  IV 

•  Pacific  Digitization 

•  Defense  Satellite  Communications  System 

•  AUTOSEVOCOM  Phase  II 

•  AUTODIN  Phase  II 

•  System  Control 

The  implementation  of  these  programs  will  have  a  significant 
impact  on  the  information  needs  of  the  major  DCS  subsystems  and  their 
organizational  elements.  The  information  needs  must  be  first 
identified  and  tabulated.  This  process  is  the  prime  concern  of  this 
section.  Subsequent  to  identification/tabulation  a  specification 
control  process  must  be  initiated  to  ensure  that  the  DCS  subsystem 
and  elements  interact  as  conceptualized.  Finally  the  information 
low  must  be  translated  into  specific  hardware/software  design  if 
the  well-being  of  the  DCS  is  to  be  sustained. 

®-.  Elements  and  Subsystems.  The  major  DCS  subsystems  are 
transmission^  switching.  Interacting  with  these  subsystems  are 
the  DCA  mission  element,  the  maintenance/operations  element,  and 
the  user  element.  These  are  depicted  in  Figure  2-1. 

The  prime  mission  of  the  Defense  Communications  Agency  (DCA) 
is  to  exercise  operational  direction  and  management  control  over  the 
DCS.  Actual  operation  and  maintenance  of  the  subsystems  are  the 
responsibi lity  of  the  MILDEP's.  The  user  and  access  areas  have  been 
historically  considered  non-DCS  elements.  These  major  subsystems 
and  elements  must  interoperate  properly  if  system  operation*  and 
performance  objectives  are  to  be  realized. 


Ideally,  data  characterizing  the  operation  and  performance 
of  a  communications  system  should  be  conveyed  to  those  elements  most 
suited  to  react  and  respond  to  the  information  received,  and  most 
capable  of  initiating  corrective  action.  The  information  needs  to 
be  considered  serve  the  maintenance,  operational  direction,  and 
management  control  elements  responsible  for  the  day-to-day  operation, 
maintenance,  short-term  direction,  and  long-term  management  functions 
of  the  DCS.  The  user  element,  beneficiary  of  the  mentioned  functions, 
also  interacts  with  DCS  networks  by  receiving  network  status 
information  and  providing  or  requesting  self  status. 

(1)  Maintenance.  The  function  of  the  maintenance  element 
is  to  restore  degraded  system  service  to  a  normal  operation  level. 
Depending  on  the  availability  and  skill  of  the  on-site  maintenance 
level,  status  information,  consisting  of  failure  and  degradation 
alarm  indicators,  is  used  to  initiate  appropriate  maintenance 
responses.  The  frequency  and  timeliness  of  the  status  information 
depend  on  whether  an  immediate  or  delayed  response  by  the 
maintenance  element  is  required. 

Local  maintenance  action  generally  involves  routine  testing, 
fault  isolation  activities,  and  minor  module  repair  or  replacement, 
and  is  usually  confined  to  personnel  associated  with  the  technical 
control  facility  (TCF),  patch  and  test  facility  (PTF),  switch 
transmission  media  and  user  equipments.  Complex  maintenance  actions 
such  as  repair  or  replacement  of  major  hardware/software  components 
involve  servicing  skills  usually  beyond  the  capability  of  the  local 
personnel.  Recent  developments  in  communications  system  design 
have  emphasized  increased  system  availability  and  reduced  dependence 
on  costly  and  numerous  on-site  maintenance  personnel  by  providing 
built-in  diagnostic  testing,  redundancy  and  restoral  features  which 
can  be  activated  locally  or  remotely.  These  features  include 
automatic  hardware  alarm  and  software  fault  check;  module  level 
testing,  troubleshooting  and  replacement;  and  module/equipment  level 
redundancy  switching  and  bypass  functions.  For  the  most  part,  however 
these  features  have  not  been  designed  into  the  DSCS  segment  of  the  DCS 

(2)  Operational  Direction.  The  primary  responsibility 
of  the  operationaT  direction  element  is  to  ensure  timely  system 
responsiveness  to  the  requirements  of  the  DCS  subscribers.  Its 
mission  includes  the  implementation  of  contingency  plans  and  the 
optimization  of  the  availability  of  communications  resources  for 
the  use  of  approved  critical  users.  Operational  direction  involves 
not  only  network  reconfiguration  and  service  extension,  but  also 
service  restoral  and  denial.  This  is  carried  out  by  exercising 
direction  over  various  subordinate  operational  elements,  by 
alerting  appropriate  operational  elements,  or  possibly  by  exercising 
direct  control  over  system  elements.  The  operational  direction 


element  utilizes  information  related  to  nodal  and  link  status, 
nodal  configuration  and  data  base,  network  traffic  status,  and 
network  performance.  Nodal  capacity,  configuration,  and  data  base 
information  provides  the  input  for  exercising  responsive  control  and 
direction  over  network  operations.  Network  traffic,  status,  and 
performance  information  assists  the  operational  direction  element 
in  detecting  and  isolating  system-level  traffic  congestions. 

(3)  Management  Control.  This  element  is  characterized  by 
long-term  functions  required  to  manage  and  improve  the  system.  It 
includes  the  establishment  of  standards,  practices,  and  procedures 
for  prescribing  system  performance,  operation,  and  maintenance. 

It  requires  non-real-time  system  information  arjd  consists  mainly 
of  data  pertaining  to  system  performance  and  system  availability 
This  information  when  correlated  with  the  network  configuration 
data  base  may  be  utilized  for  planning  and  controlling  system 
modification  and  improvement. 

(4)  User.  The  user  element  is  generally  concerned  with 
terminal  equipments  and  access  lines  and  network  interface  status 
information.  Billing  and  community  of  interest  performance  data 

are  also  of  interest  to  the  user.  Only  status  information  indicating 
service  degradation  is  provided  to  the  user  element  on  a  real  time 
basis. 

b.  Information  Exchange  Characterization.  Information  exchanges 
among  subsystems  and  elements  can  be  functionally  characteri zed  by  need, 
importance,  and  timeliness  of  the  information.  Each  piece  of  information 
has  associated  with  it  some  measure  of  each  of  these  characteristics. 

For  example,  an  information  transfer  from  one  element  or  subsystem 
to  another  is  either  needed  or  not  needed,  important  or  relatively 
unimportant,  and  real  time  or  not  real  time.  While  these  are 
admittedly  binary  classifications,  there  are  varying  degrees  for 
each  characteristic. 

(1)  Need  and  Importance.  The  need  for  and  importance  of 
information  are  direct  measures  of  its  usefulness  at  the  receiving 
end.  For  example,  timely  link  and  node  status  information  is  needed 
by  the  maintenance  element  in  detailed  form  and  by  the  operational 
direction  element  in  summarized  format.  It  is  not  needed  on  a  real 
time  basis  by  either  management  control  or  user  elements.  It  is, 
however,  information  essential  to  the  missions  of  maintenance  and 
operational  direction,  and  therein  derives  its  importance. 

(2)  Timeliness .  A  key  characteristic  of  information 
exchange  is  the  speed  of  relay  and  speed  of  response  (i.e  ,  information 
interaction  time).  Table  2-1  summarizes  the  system  information  required 
by  the  four  elements  and  the  time  parameters  associated  with  transmission 
to  and  response  from  the  elements. 
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fast  relay  and/or  response, 
delayed  relay  and/or  response. 


The  timeliness  of  information  exchange  and  control  interaction 
is  related  to  the  sampling  of  monitored  parameters  and  frequency 
of  relaying  them  to  the  appropriate  control  elements.  It  also 
relates  to  the  time  required  for  the  application  of  controls  to 
effect  improved  communications  services,  particularly  to  critical 
users.  The  above  parameters  vary  depending  on  the  causes  of  service 
degradation,  and  except  for  limited  applications  [1]  are  not  yet 
defined. 


(a)  Maintenance  And  User  Element.  The  maintenance 
element  receives  real-time  equipment  status  and  alarm  data  in 
sufficient  detail  to  enable  fault-isolation  to  equipment  or  module 
level.  The  user  element  is  provided  with  general  status  information 
from  the  network  to  prevent  unnecessary  fault-isolation  or  maintenance 
activities. 


(b)  Operational  Direction  Element.  With  the  evolution 
and  development  of  the  various  planned  DCS  subsystems,  particularly 
system  control,  the  operational  direction  element  is  envisioned  to 
be  capable  of  near  real-time  interaction,  utilizing  the  following 
information  flow  categories: 

•  Nodal/link  status  and  major  alarms 

•  Nodal  data  base,  including  nodal  configuration 

•  Nodal  traffic  status  and  performance  (data  from  which 
system  degradation  can  be  extracted;  e.g.,  network  grade  of 
service  and  speed  of  service). 

In  general,  the  nodal  data  base  component  (changes  in  nodal 
configuration,  tables,  etc.)  of  the  total  information  exchange 
will  probably  be  significant  during  crisis  situations.  The 
processing  and  storage  of  this  information  could  be  shared  or 
integrated  with  similar  management  control  functions.  System 
performance  data  may  find  use  in  assessing  the  short  term  system 
health,  as  opposed  to  the  management  control  function  which 
evaluates  the  long  term  system  health. 

Presently,  the  operational  direction  element  exercises  very 
limited  real-time  control.  In  the  future,  enhanced  capability 
will  depend  almost  entirely  on  the  SYSCON  subsystem  implementation. 

It  must  incorporate  features  that  gather,  process,  store,  display, 
summarize,  and  evaluate  or  provide  trends  from  raw  or  preprocessed 
data.  It  will  also  provide  for  appropriate  control  action  either  by 
directing  local  subordinate  elements  or  by  initiating  the  control 
action  directly. 
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The  control  actions  directed  and  applied  by  the  operational 
direction  element  are  in  response  to  system-level  problems,  such 
as  major  links  outages  or  global  switch  traffic  congestion. 

These  control  actions  will  complement  and  utilize  switch,  TCF,  and 
transmission  subsystem  control  capabilities. 

(c)  Management  Control  Element.  The  interaction  of 
this  element  with  DCS  subsystems  is  performed  entirely  on  a  non-real¬ 
time  basis,  principally  because  this  element  does  not  exercise 
functions  that  have  an  immediate  impact  on  the  network  subsystem. 

(3)  Interaction  Time.  The  information  categories  and 
associated  information  interaction  time  for  each  of  the  elements  are 
given  in  Table  2- II.  A  general  description  and  examples  of  the 
information  flows  are  also  provided. 

c.  Information  Exchanges  Tables.  The  subsystem  and  elements 
that  are  involved  in  the  information  interchange  may  be  broken  out 
as  follows: 

•  Transmission  -  consisting  of  satellite  and  terrestrial 
media  (government-owned  and  leased) 

•  Switches  -  involving  circuit,  message  and  packet  switched 
networks  (government-owned  and  leased) 

•  DCA  Mission  Related  Elements  -  consisting  of  management 
control  and  operational  direction 

•  Maintenance  and  Operation 

•  User. 

The  element  and  subsystem  interconnection  is  represented  in 
Figure  2-2.  Note  that  some  functional  blocks  are  not  paired  with 
other  blocks  since  it  is  anticipated  that  certain  elements  will  not 
require  information  exchange.  Table  2-III  is  a  matrix  identifier 
for  the  information  tables  that  follow.  Each  number  in  the  matrix 
designates  the  table  in  which  the  indicated  element/subsystem  pair 
information  exchange  may  be  found. 

Thirteen  element/subsystem  information  flow  pairs  are  presented 
in  Tables  2- I V  through  2-XVI.  Each  pair,  whether  element-to-element, 
element-to-subsystem,  or  subsystem- to-subsystem,  depicts  the  category 
of  information,  specific  examples  relevant  to  the  category,  and  the 
utility  of  the  information.  The  tabulation  is  not  intended  to  be 
complete  or  exhaustive,  but  it  does  demonstrate  the  type  of  information 
interchange  that  should  be  considered  for  both  near-term  implementation 
and  long-term  objectives. 


TABLE  2-1 1  (Cont'd).  INFORMATION  CATEGORIES  AND  ASSOCIATED  INFORMATION  INTERACTION  TIME 
Information 
Transfer  A  Control 

E’arant  Information  Category  Response  State  General  Description  4  Examples 
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Figure  2-2. 


Information  Fxchanae  Paths  Anonq  The  DCS 
Subsystems  and  Elements 


NOTE:  See  Figure  2-1  Tor  detailed  descriptions  of  the  subsystems/elements 
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TABLE  2-1 1 1  MATRIX  IDENTIFYING  TABLES  SUMMARIZING  INFORMATION 


FLOW  BETWEEN  SUBSYSTEMS  AND  ELEMENTS  PAIRS 


TABLE  2- 1 V .  INFORMATION  FLOW  FROM  NETWORK  SWITCHES  TO  MANAGEMENT  CONTROL  ELEMENT 


TABLE  2- IV  (Cont'd).  INFORMATION  FLOW  FROM  NETWORK  SWITCHES  TO  MANAGEMENT  CONTROL  ELEMENT 
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TABLE  2-V.  INFORMATION  FLOW  BETWEEN  MANAGEMENT  CONTROL  AND  NETWORK  SWITCHES 
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Assumes  TCF  or  switch  associated  PTF  scans  performance  status  of  homed  transmission  lines  and  activates  loop-back  testing  procedures  to 
isolate  line  equipments  and  user  Interface  faults  (1ST,  access  lines,  multiplexers,  crypto-equipment,  subscriber  Interface,  and  terminals). 
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III.  AUTOSEVOCOM/DIGITAL  TRANSMISSION  INTERFACE 


1.  SWITCH/TRANSMISSION  SUBSYSTEM  INCOMPATIBILITY 

Circa  1980-1982  the  Defense  Communications  Systems  will  be  of 
a  hybrid  nature.  The  overseas  backbone  transmission  plant  will  be 
extensively  digitized  both  in  Europe  and  the  Pacific  and  will  serve 
to  route  both  analog  and  digital  traffic.  The  transmission  technical 
control  facilities  (TCF),  the  interface  point  between  the  traffic 
originating  elements  and  the  backbone  transmission  subsystem,  will 
require  enhanced  capabilities  mainly  in  interfacing  with  traffic 
originating  from  digital  sources.  In  addition,  the  prospect  of 
accommodating  AUTOSEVOCOM  II  switch  requirements  in  Europe  by  utilizing 
the  TRI-TAC  developed  AN/TCC-39  has  further  highlighted  the  need  for 
an  interface  between  the  Digital  Radio  and  Multiplex  Acquisition 
(DRAMA)  transmission  subsystem  and  the  switch  subsystem.  A  viable 
interface  solution  is  necessary  since  the  switch  configurations 
for  digital  transmission  groups  are  not  adequate  for  DCS  application. 

The  basic  incompatibility  between  the  two  subsystems,  (i.e.,  the 
breakdown  and  recombination  of  inter-switch  trunks)  requires  an 
investigative  look  at  alternative  solutions. 

a.  Generic  Technical  Control  Subsystem.  Figure  3-1  generically 
represents  a  TCF  partitioned  into  analog  and  digital  sections.  The 
analog  portion  provides  the  same  functions  as  present  day  analog  TCF 1 s 
including  circuit  conditioning,  signaling  and  ancillary  equipment  for 
testing  dedicated  and  switched  voice,  facsimile,  teletype,  and 
medium-speed  modem  driven  data  circuits.  The  digital  portion  of  the 
TCF  provides  signal  conditioning,  buffering,  grouping  and  multiplexing 
functions  for  synchronous  data  streams.  Combining  and  interfacing 
asynchronous  data  streams  also  occurs.  The  facility  will  provide  the 
normal  technical  control  functions  of  circuit  restoral  and  extension, 
testing  and  fault  isolation,  coordination  with  operation/maintenance 
elements,  and  reporting  to  operational  direction  and  management  control 
elements. 

b.  Circuit  Distribution  at  TCF.  The  partitioning  of  the  TCF 

into  analog  and  digital  parts  is  based  on  functional  requirements.  These 
parts  will  not  accommodate  similar  circuit  loading  requirements.  Based 
on  projected  circuit  and  traffic  requirements  (1985-88),  it  appears 
that  the  bulk  of  the  circuit  appearances  at  the  TCF  will  be  analog. 

Secure  voice  circuits  will  comprise  less  than  10®,  and  data  circuits 
about  24%  of  the  total  circuits.  Figure  3-2  illustrates  a  typical 
link  cross-section  with  these  percentages  identified. 


DEDICATED  VOICE 


Figure  3-2.  Typical  Link  Cross-Section  Distribution 
Based  upon  Random  Sampling  of  15  Links  of 
Projected  1^85 -198?  Circuit  Requirements 


c.  Digital  Interface.  Table  3-1  summarizes  the  major  switch/ 
transmission  characteristics  and  other  considerations  affecting  the 
digital  interface.  Most  switches  will  be  configured  with  one  time 
division  matrix  (TDM\)  with  four  digital  transmission  groups,  each 
containing,  on  the  average  more  than  one  Inter  Switch  Trunk  (1ST). 

Since  the  mean  switch  connectivity  requirement  exceeds  six  1ST  groups 
there  is  a  definite  need  to  break  down  and  recombine  the  four  digital 
transmission  groups.  This  is  the  main  task  of  the  interface  which 
will  be  incorporated  at  the  digital  TCF.  A  summary  of  the  major 
digital  interface  requirements  is  contained  in  Table  3- II. 

2.  INTERFACE  CONCEPTS 

In  order  to  resolve  the  interface  issue,  three  basic  concepts  are 
defined.  The  first  involves  integrated  interface  of  analog  and  digital 
channels.  This  concept  utilizes  nontradi tional  technology  and  operations 
at  the  TCF.  The  second  concept  involves  preservation  of  the  traditional 
configuration  and  operations  of  the  TCF.  Under  this  concept,  two 
alternatives  are  evaluated.  The  last  concept  involves  specialized 
interface  for  AUTOSEVOCOM  II  traffic  requiring  nontradi ti onal  technology 
and  operations  at  the  TCF.  Three  subalternatives  are  evaluated  for 
this  concept. 

a.  Concept  I.  The  concept  I  interface  interacts  with  (1) 
digitized  voice  frequency  channels  at  the  output  of  the  DRAMA  first 
level  multiplexer,  and  (2)  secure  voice  digital  groups  and  data  channels. 
These  digital  streams  are  brought  to  a  common  route  and  format  before 
they  are  directed  to  a  channel  assignment  device  (i.e.,  TDMX)  which 
performs  channel /group  sequence  arrangements  among  the  group  inputs. 

The  outputs  of  the  channel  assignment  device  (CAD)  are  1.544  Mb/s 
groups  which  are  passed  through  bulk  encryption  devices  (i.e.,  KG- 81) 
to  the  second  level  multiplexer.  Since  the  CAD  addressing  can  be 
remotely  updated,  its  useage  as  a  nodal  element  offers  enhanced 
flexibility  and  the  potential  for  reduced  O&M  in  the  areas  of  channel /group 
restoral  and  reconfiguration.  Figure  3-3  depicts  the  interface 
functionally.  The  PCM  digroup  output  streams  enter  the  CAD  directly 
whereas  other  digital  streams  are  conditioned  and  multiplexed  when 
necessary,  prior  to  entering  the  CAD.  The  fioure  also  shows  the 
percentage  of  special  purpose  user  traffic  ar  1  switched  traffic  within 
the  DCS.  Under  Concept  I,  the  AUTOSEVOCOM  II  interface  requirements 
are  met  as  part  of  achieving  an  integrated  and  flexible  voice/data 
channel  or  group  reconfiguration  capability. 

b.  Concept  II.  This  concept  utilizes  conventional  multiplexers 
to  interface  AUTOSEVOCOM  II  channels  with  the  digital  transmissions. 

Two  distinct  alternatives  are  shown  in  Figure  3-4.  In  alternative  1, 
the  1ST  digital  groups  generated  by  the  TTC-39  switch  are  demultiplexed 
to  16  kb/s  channels.  These  are  then  grouped  into  streams  suitable  for 
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transmission.  Alternative  2  involves  the  modification  of  the  digital 
portion  of  the  AN/TTC-39  switch  to  output  16  kb/s  trunks.  The  function 
of  the  interface  is  to  group  the  channels  into  streams  using  conventional 
multiplexers. 

c.  Concept  III.  Concept  III  employs  a  channel  reassignment 
function  (CRF)  device  [2],  This  device  is  a  programmable  multiplexer 
that  essentially  utilizes  a  time  division  switch  matrix  to  provide 
AUTOSEVOCOM  II  connectivity  requirements.  Functionally,  the  CRF 
operates  similar  to  the  CAD  of  Concept  I  except  it  interfaces 
AUTOSEVOCOM  II  traffic  exclusively  at  rates  and  formats  specified 

by  reference  [3].  The  outputs  of  the  CRF  are  routed  to  the  data 
interleaving  ports  of  the  first  level  PCM  multiplexer. 

d.  Concept  Comparison.  Table  3- 1 1 1  gives  a  comparison  of  the 
main  features  of  the  three  concepts.  Concept  I  provides  integrated 
TCF  capabilities  with  the  potential  for  automation  and  operation  and 
maintenance  savings.  This  concept,  however,  appears  to  incur  greater 
initial  costs  and  greater  technical  and  schedule  risks  and,  therefore, 
is  considered  not  applicable  in  the  near-time  frame  (i.e.,  1980). 

In  the  long  term,  it  offers  certain  subsystem  advantages  and  is  being 
analyzed  under  DCA  study  Contract  (DCA  100-76-C-0064) ;  it  will  not 
be  further  addressed  herein. 

Note  that  all  three  concepts  utilize  common  channel  signaling. 
This  form  of  1ST  signaling  requires  preservation  of  the  prearranged 
trunk  time  slot  sequence  that  form  the  trunk  groups  so  that  the 
location  of  the  overhead  (signaling)  channels  and  associated  trunks 
are  known  at  all  switches  [4].  Changes  of  the  trunk  group  order 
at  the  transmission  end  must  be  performed  in  coordination  with  the 
switches  affected. 

e.  Alternative  Solutions  for  Concept  II  and  III.  Figure  3-5 
shows  the  solution  alternatives  for  the  TCF/Switch/Transmission 
interfaces.  This  figure  gives  a  different  perspective  than 
Figure  3-4,  which  serve  to  accent  the  interface  discussions. 

(1)  Alternative  1 .  (Concept  II.)  1ST  digital  groups  are 
demultiplexed  into  baseband  16  kb/s  channels,  and  selected  overhead 
channels  are  broken  out  to  terminate  2  kb/s  system  control  (SYSCON) 
subchannels.  The  subchannels  are  recombined  and  multiplexed  with 
other  16  kb/s  channels  to  yield  digital  groups  suitable  for 
transmission  to  other  nodal  points. 

(2)  Alternative  2.  (Concept  II. |  AN/TTC-39  switches  have 
been  assumed  to  be  modified  to  output  individual  16  kb/s  trunks  in 
place  of  1ST  groups.  In  addition  to  reducing  switch  equipments  such 
as  group  multiplexers,  framing  and  buffering  elements,  this 


1 1 1-9 


alternative  results  in  considerable  switch/transmission  interface 
simplification.  16  kb/s  overhead  channels  are  demultiplexed  to 
provide  SYSCON  channel  appearance,  and  then  are  recombined  and 
multiplexed  with  other  sixteen  kb/s  channels  as  in  alternative  1. 

(3)  Alternative  3  (Concept  III.)  This  alternative 
incorporates  modules  of  the  digital  elements  of  the  TCCF  communications 
nodal  control  equipment  (CNCE)  being  developed  for  the  TRI-TAC  program. 
Three  subalternative  designs,  with  varying  capabilities,  complexities, 
and  modifications  are  given  in  Figure  3-6.  The  common  element  for 
alternative  3  is  the  Channel  Reassignment  Function/Automatic 
Digital  Tester  (CRF/ADT) .  The  ADT  enables  generation  and  monitoring 
of  digital  streams  through  any  selected  channel  for  the  purpose  of 
determining  average  bit  error  rates.  A  brief  description  of  the 
subalternatives  is  presented  below.  Detailed  discussion  is  included 
in  a  DCEC  internal  memo  [5]. 

(a)  Subalternative  3A.  Major  digital  interface  elements 
of  the  CNCE  (Type  III),  as  specified  in  reference  [6],  are  considered 
in  this  subalternative.  Specifically,  the  processor  subsystem,  channel 
reassignment  function,  ADT  visual  display  unit,  hard  copier,  and  a 
3-channel  submultiplexer  for  channel  packing  to  16  kb/s,  are  considered. 

(b)  Subalternative  3B.  This  subalternative  uses  a 
microprocessor  in  place  of  the  CNCE  processor  subsystem.  The 
remaining  elements  are  identical  to  those  of  subalternative  A. 

(c)  Subalternative  3C.  This  subalternative  utilizes 
the  CRF  and  ADT  in  the  manual  mode  Tn  a  configuration  resembling  CNCE 
(Type  VI)  [6].  The  CRF  is  modified  to  include  the  I/O  port  for  possible 
interface  with  higher  echelon  SYSCON  elements.  No  processing  or 
display  subsystems  are  included. 

(d)  Variations  in  Alternatives.  Certain  reasonable 
variations  in  each  alternative  can  be  described.  Since  all  TCF’s 
will  be  collocated  with  switches,  the  need  to  deploy  modems,  both 
channel  and  group,  to  drive  digital  signals  through  a  cable  medium 
is  obviated.  Detailed  discussion  of  variations  in  alternatives  is 
contained  in  reference  [5], 

3.  ALTERNATIVE  EVALUATION 

The  three  alternatives  were  evaluated  using  the  methodology 
described  in  reference  [5],  Thirteen  possible  combinations  are 
ranked  in  ascending  order  (i.e.,  1-13),  1  being  best,  and  are  shown 
in  Table  3- I V .  The  following  discussions  provide  the  rationale  for 
scoring. 
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a.  Basic  Requirements.  All  alternatives  were  configured  to 
match  the  AUTOSEVOCOM  II  interface  requi rements :  routing  of  IST's, 

DAX  access  lines,  and  loops.  They  also  provide  the  SYSCON  subchannels. 
Alternative  3,  when  not  configured  to  generate  channel  grouping  of 
three  16  kb/s  channels,  was  ranked  lower  in  the  area  of  efficient 
transmission  utilization. 

b.  Syscon  Requirements.  Alternative  3  is  in  general  superior  In 
providing  semiautomatic  means  for  subchannel,  channel,  and  group 
configurations.  Subalternative  3C  was  ranked  higher  than  alternatives 
1  and  2  on  the  assumption  that  the  CRF  could  be  easily  modified  to 
interface  with  the  higher  levels  of  operational  direction. 

c .  Cost  Consi deration 

(1)  Switch  Nodal  Costs.  Figures  3-7  through  3-9  depict 
the  hardware  costs  versus  the  total  AUTOSEVOCOM  II  channels  at  various 
European  switch  nodes.  The  nodal  costs,  in  general,  are  not  simple 
functions  of  the  numbers  of  channels,  but  rather  depend  on  the 
actual  node  and  switch  configurations  defined  by  factors  such  as: 
terminating  channels  and  digital  groups,  local  loops,  through-groups 
and  branching  groups,  connectivity,  and  submultiplexer  modularity. 

In  the  cost  figures  shown,  these  factors  in  conjunction  with 
the  AUTOSEVOCOM  II  Network  sizing  [3]  are  used  to  estimate  the 
costs  of  the  switch  nodes  at  sampled  DCS  locations.  These  locations 
include  Feldberg,  Langerkopf,  and  Coltano. 

Alternative  costs  at  other  switch  nodes  are  interpolated,  using 
total  number  of  channels  as  a  parameter,  from  the  estimated  costs  at 
the  mentioned  nodes. 

From  these  figures,  subalternative  3A  is  the  most  costly  and  is 
relatively  independent  of  node  size.  As  the  node  size  decreases,  the 
cost  of  the  other  alternatives  is  reduced. 

For  all  of  the  alternative  variations,  b  and  c  appear  the  most 
reasonable  because  the  switch  and  TCF  will  be  collocated.  The  cost 
curves  for  these  variations  indicate  that  alternatives  lb,  2b,  3Cb, 
and  3Cc,  which  involve  manual  operation,  result  in  the  lowest  cost. 

The  cost  estimates  are  based  on  data  provided  by  [7],  internal 
memoranda,  and  reports.  No  attempt  has  been  made  to  estimate 
installation,  integration,  software,  spares,  and  logistics  costs. 

It  is  assumed  that  those  factors  will  further  improve  alternatives 

1,2,  and  3c.  The  cost  impact,  Incurred  from  switch  modifications, 
were  not  evaluated. 
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(2)  System  Costs.  The  majority  of  DCS  nodes  currently  are 
obviously  not  switched  nodes.  Most  nodes  serve  mainly  as  drop  and 
insert  or  through-group  and  branching  nodes.  Figure  3-10  provides  a 
histogram  of  projected  European  AUTOSEVOCOM  II  DAX  trunks,  which  is 
based  on  a  specific  network  sizing  [3],  The  alternative  costs 
associated  with  DAX  nodes,  direct  homed  subscriber  drop  and  insert 
nodes,  and  through-group  and  branching  nodes  are  shown  in  Figure  3-11. 

It  is  apparent  that  from  the  system  cost  view,  alternatives  1  and  2  are 
better  than  alternative  3. 

d.  Technical  Risks.  The  multiplexers  considered  in  alternatives 
1  and  2  are  noninventory  items.  However,  similar  hardware  being 
developed  under  the  TRI-TAC  program,  is  characterized  by  off-the-shelf 
technology  and  known  design  techniques.  Therefore,  these  alternatives 
are  ranked  as  high  as  3Ca  and  3Cb,  which  have  been  developed.  The 
remaining  alternatives  involve  changes  to  specification,  software 
development,  or  new  design,  and  thus  have  a  higher  risk. 

e.  Schedule  Risk.  Only  alternatives  3A  (a,b),  3C  (a,b)  are 
currently  programmed  for  development  and  deployment  (TCCF  program). 

A  slip  in  the  program  due  to  problems  on  CNCE  software  development  will 
affect  the  1980  production  objective.  Alternative  1,  if  programmed 
within  a  year  should  not  result  in  schedule  risk.  Alternative  2 
involves  specification  change  in  the  TTC-39  switch,  and  therefore 
may  incur  considerable  schedule  risks.  The  remaining  alternatives 
involve  various  modifications  in  software,  hardware,  and  therefore 
high  schedule  risk. 

f.  Applicability.  This  criterion  ranks  the  applicability  of  each 
interface  alternative  to  the  various  DCS  nodes.  Based  upon  costs  and 
risks  factors,  alternatives  1  and  2  were  evaluated  to  be  best.  A  hybrid 
alternative  employing  CRF  at  switch  nodes  and  conventional  multiplexers 
at  other  nodes  is  also  possible.  The  cost  of  this  configuration  will 

be  substantially  lower  than  that  of  the  "pure"  CRF  alternatives,  but 
higher  than  the  "pure"  multiplexer  alternative. 

g.  0&M.  Training  in  new  skills,  operational  familiarity,  and 
ease  of  operation  favors  alternatives  1  and  2.  The  operational  manning 
level  required  is  assessed  to  be  about  the  same  for  all  alternat:  -es, 
with  the  possible  exception  of  alternative  3C  where  the  operational 
complexity  may  increase  personnel  level.  Alternatives  employing 

CRF  have  potential  for  future  remote  operation. 

h.  FI  ex i b i 1 i ty .  All  alternatives  are  modular  and  will  accommodate 
growth  or  changes  in  AUTOSEVOCOM  nodal  traffic. 

i •  Maintainabi 1 i ty.  This  criterion  is  primarily  a  function  of 
the  equipment  complexity and  sophistication;  consequently,  alternatives 
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Figure  3-10.  Histogram  of  the  Number  of  DAX  Nodes  vs 
the  Total  Number  of  DAX  Trunks 


3 1 1 -20 

1 


1 


COST  ( $K) 


LEGEND 


1  and  2  rank  the  highest.  Alternative  3  which  is,  in  effect,  a  time 
division  matrix  would  require  specially  trained  personnel  to  maintain 
the  software  (3A  and  3B)  and  the  relatively  complex  hardware. 

j.  Communications  Availability.  Failure  of  a  given  multiplexer 
results  in  outage  of  channels  associated  with  that  particular  multiplexer. 
Failure  of  the  CRF  memory  results  in  to.al  nodal  channel  outage. 

In  short,  given  the  same  fault  conditions,  alternatives  1  and  2 
involve  "graceful"  degradation,  whereas  alternative  3  may  result 
in  total  outage. 
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TRANSMISSION  DIGITIZATION  STRATEGY 


This  issue  is  concerned  with  achieving  a  viable  strategy  for 
digitizing  predominately  analog  DCS  traffic  as  the  DCS  transitions 
to  an  all-digital  system.  As  such,  it  has  significant  implications 
with  respect  to  frequency  spectrum  utilization  and  ease  of  transition. 
Background  information  is  provided  on  commercial,  current  DCS,  and 
transitional  DCS  digitization  considerations.  Traffic  growth 
projections  are  presented  to  indicate  the  percentages  of  traffic  that 
can  be  expected  to  be  digital  and  to  indicate  the  relative  percentages 
of  terminals  that  will  not  originate  digital  traffic.  The  framework 
is  then  provided  in  which  the  digitization  alternatives  are  discussed. 

A  comparison  of  certain  A/D  techniques  is  presented  and  their  application 
in  the  transitional  DCS  is  discussed. 

1.  DIGITIZATION  CONSIDERATIONS 

The  digitization  strategy  for  the  DCS  (non-AUTOSEVOCOM)  has  been 
based  on  the  conversion  of  4  kHz  analog  voice  channels  to  64  kb/s 
pulse  code  modulation  (PCM)  digital  channels  [8].  This  technique  was 
chosen  because  it  is  proven  [9],  and  because  it  meets  the  DCS 
performance  requirements  imposed  by  the  existing  analog  plant,  the 
more  important  of  which  are:  tandeming  (i.e.,  multiple  analog-to- 
digital  (A/D)  and  D/A  conversions)  and  the  ability  to  convert 
quasi-analog  signals  to  a  digital  format  [8]. 

However,  it  appears  that  this  digitization  technique  is 
bandwidth  inefficient  as  compared  to  other  A/D  techniques,  in  that 
one  4  kHz  voice  channel  requires  64  kb/s.  This  bandwidth  problem 
raises  questions  of  spectrum  utilization  stemming  primarily  from  DCS 
frequency  and  bandwidth  allocations  in  Europe.  For  example,  given  a 
14  MHz  bandwidth,  it  is  possible  to  obtain  approximately  600  4  kHz 
channels  using  FDM/FM  techniques;  whereas,  using  64  kb/s  PCM,  only 
192  equivalent  4  kHz  voice  channels  are  possible  for  the  same  14  MHz 
bandwidth  as  implemented  in  the  FKV  program  [10], 

To  alleviate  this  problem,  another  possible  digitization  strategy 
has  been  proposed.  This  is  the  use  of  delta  modulation  (DM)  for 
improved  coding  of  voice.  Compared  to  64  kb/s  PCM,  an  improvement 
in  the  voice  handling  capacity  of  transmission  equipments  by  a  factor 
of  approximately  two  is  possible  with  DM  at  3?  kt's.  However,  it 
does  not  have  the  "drop-in"  adequacy  that  PCM  ha  n  the  analog  plant. 

The  trend  toward  PCM  has  evolved  primarily  because  of  i * , 
complete  transparency  to  all  analog  traffic,  a  factor  which  influenced 
Ai&T  s  digital  growth  strategy  centered  around  64  kb/s.  Also, 
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European  common  carriers  have  conceptualized  systems  based  on  64  kb/s 
derived  channels.  However,  there  is  also  a  trend  toward  DM  as  exhibited 
by  the  availability  of  DM  multiplex  equipment  from  European 
manufacturers  and  its  use  as  a  voice  encoding  scheme  in  the  TR1-TAC 
program,  EUROCOM  program,  Phase  II  secure  voice,  etc. 

a.  Commercial .  Commercial  equipment  is  available  today  which 
employs  64  kb/s  PCM  (e.g.,  AT&T's  T-carrier  system).  Likewise,  32  kb/s 
DM,  the  Phillips  Type  8TR610  DELTAMUX,  and  similar  equipments  produced 
by  Siemens,  Marconi,  and  Ericson,  are  commercially  available. 

b.  Current  DCS  Digitization.  The  initial  upgrade  of  the  DCS 

transmission  plant  has  replaced  analog  (FDM)  derived  4  kHz  channels 
with  digital  64  kb/s  PCM  channels  accompanied  by  specific  changes  in 
network  sizing  to  accommodate  current  and  projected  near-term 
requirements.  The  FKV  transmission  system  upgrade  program  [10]  is 
presently  operating  on  a  PCM/TDM/FM  hierarchy,  with  bulk  encryption; 
high-speed  data  traffic,  and  digital  voice  traffic  are  passed 
over  the  system.  This  hierarchy  is  shown  in  Figure  4-1. 

c-  DCS  Transition.  The  transition  of  DCS  transmission  from 
analog  to  digital  is  planned  to  be  accomplished  principally  with 
equipment  to  be  procured  for  the  Digital  Radio  and  Multiplex 
Acquisition  (DRAMA)  transmission  subsystem.  The  primary  multiplex 
equipment  will  utilize  64  kb/s  PCM.  It  will  also  have  the  capability 
to  accept  digital  signals  directly. 

2.  OVERSEAS  TRAFFIC  GROWTH  PROJECTIONS 

The  bulk  of  present  DCS  service  is  devoted  to  4  kHz  analoq 
r0^0'/,  ?lg’ta  serv1ce  is  provided  by  the  present  AUTODIN  I  system. 

Table  4-1  shows  the  percentage  of  DCS  circuits  utilized  to  provide  the 
sted  services  based  upon  the  modulation  rate  carried  within  the 
rw«ean  dn^  Pa^lflc  areas-  Typical  link  cross-sections  based  on 

t!k?  V?TP  eTufr0rn  both  the  Eur°Pean  and  Pacific  areas  are  given  in 
Table  4-II.  This  table  highlights  the  analog  nature  of  the  DCS. 

, .  .  a*  European ._  Currently,  17%  of  the  average  terrestrial  analoa 
ink  channel  capacity  is  devoted  to  carrying  digital  traffic  in  Europe 

dKr:"°^el 

enPc™;Tn  '980>  and  t0  a,1°"  for  backbone  network 

projections  for  rtZ  ^7™'  maj0r  DCS  pro9ram  plans*  traffic 

c  f  and  secure  voice,  data,  and  narrative/record 

service  are  given  in  Table  4- 1 1 1 .  As  seen  from  Figure  4-2  bv  ?988 
approximately  61%  of  the  DCS  European  transmission  plant  wil/be  digital. 
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Figure  4-1.  FKV  Configuration 


TABLE  4-1.  PERCENTAGE  OF  DCS  CIRCUIT  CAPACITY  UTILIZED  TO  PROVIDE 


Speech  Plus/VFCT 


TABLE  4- II I.  EUROPEAN  GROWTH  TRENDS* 


*Based  on  current  program  plans  and  Pit  rates 
♦Includes  European  Telephone  System  ( ETS)  Network. 
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Figure  4-2.  Percentage  of  Analog  and  Digital  Tran 


However,  as  can  be  seen  from  Table  4-1 1 1  It  s  than  1  O'  of  the  total 
traffic  erlangs  introduced  into  the  system  will  have  originated  from 
digital  terminals.  The  projections  given  assume  no  major  perturbations 
and  that  there  is  no  pressure  to  convert  clear  voice  terminals  to 
digital  operation. 

b.  Paci f i c .  Of  the  average  terrestrial  analog  link  capacity, 

14  is  devoted  to  carrying  digital  traffic  in  the  Pacific.  As  in 
Europe,  the  motivating  factor  for  digitization  is  the  need  to  satisfy 
near-term  program  plans  and  to  allow  backbone  encryption.  Based  on 
current  major  DCS  program  plans,  traffic  orojections  for  clear  and 
secure  voice,  data,  and  narrative/record  services  are  given  in 
Table  4- 1 V .  As  seen  from  Figure  4-3,  by  1988  approximately  80  of 
the  DCS  Pacific  transmission  plant  will  be  digital.  However,  less 
than  15  of  the  total  erlangs  of  traffic  introduced  into  the 
system  will  have  originated  from  digital  terminals  [11].  Again, 
no  major  perturbations  or  pressures  to  convert  from  analog  to 
digital  terminals  are  assumed.  As  may  be  seen  from  these  tables 
and  figures,  DCS  digitization  will  be  heavily  concentrated  in  the 
backbone  network  rather  than  in  the  accec<.  area,  with  the  exception 
of  the  AUT0SEV0C0M  II  program,  which  will  employ  a  100  digital  secure 
voice  strategy. 

3.  DIGITIZATION  STRATEGIES 

The  traffic  projections  presented,  together  with  the 
percentages  of  digitization,  provide  a  measure  for  understanding 
digitization  alternatives. 

The  alternatives  for  digitization  discussed  below  are  not  concerned 
with  a  strategy  for  digital  conversion  of  clear  voice  and  modem  derived 
data  from  their  present  analog  state.  Rather,  the  alternatives  treat 
A/D  conversion  in  the  DCS  transmission  subsystem  only.  Of  importance, 
however,  is  the  application  of  these  alternatives  to  communities  of  clear 
voice  subscribers,  specifically,  clear  voice  AUT0V0N  and  the  European 
Telephone  System. 

a.  A1 ternati ve  1 .  This  alternative  addresses  the  currently  planned 
64  kb/s  PCM/TDM  digitization  strategy.  Figure  4-4  presents  a  simple 
view  of  this  alternative.  The  PCM  multiplex  will  accept  up  to  twenty 
four  4  kHz  analog  voice  channels  and  output  a  1.544  Mb/s  data  stream 
to  the  second  level  MUX.  It  will  be  possible  to  replace  up  to  12 
voice  channels  in  each  digroup  with  digital  data  channels  of  any  of 
the  following  types: 
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TABLE  4- 1 V .  PACIFIC  GROWTH  TRENDS* 
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*Based  on  current  program  plans  and  bit  rates  therein  assoc 
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(1)  50  kb/s  asynchronous 

(2)  56  or  64  kb/s  synchronous 

(3)  128,  256  or  512  kb/s  synchronous 

(4)  0-20  kb/s  asynchronous. 

Each  channel  of  the  above  data  sources  except  (3)  shall  displace  one 
voice  channel.  Each  128,  256,  or  512  kb/s  data  channel  shall 
displace  two,  four,  or  eight  voice  channels  respectively. 

b.  Alternative  II.  Figure  4-5  chows  a  simple  breakout  of  this 
alternative.  It  is  characterized  by  the  same  24  channel  PCM  MUX  as 
in  alternative  1.  However,  a  DM  MUX  in  the  form  of  continuous  variable- 
slope  delta  (CVSD)  modulation  has  been  added  which  will  accept  up  to 
forty  five  4  kHz  analog  voice  channels  and  output  a  1.544  Mb/s  data 
stream.  This  stream  will  comprise  forty  five  32  kb/s  data  streams 
plus  overhead  to  build  up  to  1.544  Mb/s.  The  CVSD  MUX  will  be  used 
strictly  for  clear  voice  A/D  conversion  because  it  is  known  that  CVSD 
cannot  accommodate  the  variety  of  quasi-analog  signals  expected  in 
the  DCS.  Signaling  and  supervision  signals  are  not  passed  through 
the  CVSD  circuitry  of  the  MUX,  but  rather  are  detected  and  then 
converted  by  separate  circuitry. 

This  alternative  has  the  advantage  of  employing  DM  at  a  lower 
basic  bit  rate  than  PCM,  and  hence  can  make  for  more  efficient  use 
of  available  bandwidth  than  alternative  1.  This  point  becomes  more 
pronounced  if  the  CVSD  conversion  rate  is  halved  to  16  kb/s,  so  that 
SO  channels  could  be  accommodated. 

4.  COMPARISON  OF  DM  AND  PCM 

The  salient  differences  between  64  kb/s  PCM  and  32  kb/s  DM  are 
depicted  in  Table  4-V.  Because  32  kb/s  DM  approximately  doubles 
the  channel  capacity  of  64  kb/s  PCM,  DM  is  more  bandwidth  efficient 
than  PCM. 

In  some  respects,  the  DM  coder  is  easier  to  implement  and  therefore 
potentially  less  costly  than  the  PCM  coder.  This  arises  because  no 
expensive  filters  with  steep  slopes  are  required  and  the  DM  has  many 
building  blocks  which  are  identical.  The  DM  encoder  is  also  simpler 
because  it  does  not  require  the  word  synchronization  which  is  necessary 
for  PCM.  In  the  1 960 ’ s ,  the  advantage  of  PCM  was  that  a  coder  could 
be  shared;  however,  today  more  PCM  multiplexers  are  using  a  single 
encoder  per  channel  to  avoid  analog  cross  talk  involved  in  switching 
the  PCM  i  'coder  between  channels. 

The  effect  of  channel  errors  upon  PCM  is  more  severe  than  DM 
because  there  is  a  hierarchy  to  the  transmitted  PCM  signal;  i.e.,  an 
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TABLE  4-V.  COMPARISON  OF  64  kb/s  PCM  AND  32  kb/s  DM 


error  in  the  most  significant  bit  of  a  PCM  codeword  can  lead  to  an 
error  as  great  as  2  quantization  levels.  Even  worse,  word  synchroniza¬ 
tion  can  be  lost  with  PCM. 

The  main  advantage  of  64  kb/s  PCM  is  that  it  can  be  incorporated 
into  a  4  kHz  analog  communications  system  with  little  or  no  adverse 
effect;  i.e.,  it  can  pass  analog  voice  as  well  as  quasi-analog 
signals  through  many  A-to-D  and  D-to-A  tandem  conversions.  On  the 
other  hand,  DM  is  limited  to  a  range  of  4  to  8  A  to  D  and  D  to  A  conversion 
and  is  also  limited  with  respect  to  quasi-analog  signals,  especially 
these  above  2  kHz. 

5.  APPLICATION  OF  DM  TO  THE  DCS  IN  EUROPE 

Table  4- 1 1 1  projects  that  by  1988  clear  voice  traffic  in  Europe, 
including  clear  voice  AUTOVON  and  ETS  traffic,  will  increase 
significantly.  This  is  important  when  considering  possible  traffic 

classes  that  may  be  included  in  the  digital  transmission  subsystem, 
in  terms  of  the  mentioned  alternatives. 

It  is  known  that  PCM  in  alternative  I  will  accommodate  these 
classes  of  analog  traffic  and  any  quasi-analog  signal  traffic, 
bandlimited  to  4  KHz.  However,  the  DCS  is  experiencing  difficulty 
in  obtaining  the  required  bandwidth  to  support  digital  traffic. 

Spectrum  efficiency  is  therefore  of  utmost  importance. 

The  application  of  a  DM  multiplex  to  the  transmission  subsystem, 
alternative  II,  has  spectrum  efficiencies  when  compared  to  PCM. 

Since  DM  does  not  handle  quasi-analog  traffic  satisfactorily,  it  is 
suggested  that  DM  could  be  used  for  clear  voice  subscribers  only. 

The  problems  of  signaling  and  supervision  over  voice  networks  can 
be  accommodated  using  commercially  available  signal  converters. 

Hence,  both  clear  voice  AUTOVON  and  ETS  traffic  appear  to  be 
excellent  candidates  for  DM  at  32  kb/s,  particularly  when  used  under 
short  tandem  conditions.  Furthermore,  both  systems  are  located  in 
a  region  where  frequency  allocation  problems  persist  (i.e.,  Europe). 

To  quantify  this,  the  baseline  DCS,  circa  1980,  as  defined  in  the 
Mix  of  Media  Study  [12]  was  analyzed.  The  results  of  this  analysis 
are  given  in  Figure  4-6,  which  shows  the  average  percentage  increase 
in  available  channels  for  48,  96,  144,  194,  288,  and  384  channel 
digital  radio  links  in  Germany  when  converted  from  64  kb/s  PCM  to  32 
kb/s  DM.  The  percentage  increase  is  considered  to  be  a  best  estimate, 
as  efficient  multiplex  grouping  is  assumed.  The  links  of  primary 
importance  are  the  288  and  384  channel  systems,  since  they  require 
bandwidths  in  excess  of  7  MHz.  In  order  to  achieve  a  significant 
bandwidth  reduction  for  these  links,  (i.e.,  from  14  MHz  to  7  MHz), 
the  number  of  64  kb/s  channels  required  would  have  to  be  reduced 


by  approximately  25"  for  the  288  channel  links  and  50%  for  the  384 
channel  links.  Of  the  384  channel  links  (22  in  Germany),  the  highest 
channel  reduction  achieved,  using  32  kb/s  DM,  was  about  39%.  This  was 
for  the  Donnersberg-Sembach  link.  Of  the  288  channel  links  (14  in 
Germany),  only  two  showed  a  significant  bandwidth  reduction.  These 
were  the  Schwanberg-Wurzburg  and  the  Brandhof-Nuernberg  links.  On  the 
basis  of  these  results,  32  kb/s  DM  would  not  significantly  reduce  the 
bandwidth  requirements  in  Europe,  but  it  would  increase  channel  capacity 
by  15-25%.  An  additional  analysis  including  all  clear  voice  traffic, 
along  with  ETS  and  AUT0V0N,  did  not  show  a  significant  change  in  the 
results . 

An  additional  application  for  DM  at  32  kb/s  is  increasing 
the  capacity  of  leased  DCS  transoceanic  IST’s.  Here,  the  payoff  is 
a  clear  doubling  of  the  channel  capacity  as  compared  to  64  kb/s  PCM. 
However,  because  DM  might  not  pass  certain  quasi-analog  traffic, 
particularly  high  speed  data  at  9.6  kb/s  and  some  medium  speed  data 
at  4.8  kb/s,  certain  provisions  for  these  traffic  types  would  be 
necessary. 

6.  ASSESSMENT  OF  ALTERNATIVES 

Both  digitization  alternative  I,  PCM,  and  digitization 
alternative  II,  PCM  and  DM,  have  certain  advantages  and  disadvantaaes 
which  have  been  evaluated.  To  assess  the  effectiveness  of  each 
alternative,  a  set  of  measures  of  effectiveness  (MOE)  was  devised. 

Each  measure  is  assigned  a  weight  based  upon  its  estimated  importance 
to  the  DCS.  Each  alternative  is  then  given  a  rank  for  each  MOE  based 
upon  the  analyses  as  described  below.  Finally,  a  figure  of  merit  was 
obtained  for  each  alternative  by  summing  the  weight  and  rank  for  each 
MOE . 


a.  Bandwidth  Reduction.  This  measure  considers  the  bandwidth 
reduction  that  may  be  possible  by  using  more  efficient  A/D  techniques. 
It  has  been  shown  that  the  use  of  32  kb/s  delta  modulation  for 
certain  clear  voice  DCS  subscribers  in  Europe  would  not  result  in 
significantly  lower  bandwidth  requirements  over  64  kb/s  PCM  for  the 
DEB.  Each  alternative  is  then  given  an  equally  low  rating. 

b.  Capacity.  This  measure  of  effectiveness  evaluates  the 
potential  increase  in  capacity  or  growth  that  one  alternative  has  over 
the  other.  As  has  been  discussed,  alternative  II  has  a  higher 
channel  capacity  than  alternative  I  because  approximately  two  32  kb/s 
DM  voice  channels  can  replace  one  64  kb/s  PCM  voice  channel. 

c.  Ease  of  Through-Grouping.  This  is  a  measure  of  the 
efficiency  of  the  multiplex  equipment  in  reducing  the  number  of 
conversions  to  the  baseband  level.  Alternative  I  is  better  in  that 
all  traffic  will  be  converted  to  64  kb/s  PCM  and  multiplexed  in  24 
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channel  groups.  Conversely,  alternative  II  does  not  lend  itself 
to  ease  of  through-grouping  because  of  the  additional  multiplex 
equipment  required  for  DM.  The  DM  multiplex  will  group  45  channels 
at  an  output  rate  of  1.544  Mb/s.  Other  lower  order  DM  MUX's  will 
be  required  for  group  modularities  less  than  45  channels,  thus 
further  complicating  the  multiplex  hierarchy. 

d.  Ease  of  Transi tion.  In  the  near  term  (early  1980's),  PCM 
is  superior  to  DM  in  that  it  can  be  placed  in  an  analog  system  and 
appear  transparent  to  all  the  various  types  of  traffic  being  transmitted 
through  the  system.  This  is  not  true  of  DM. 

In  the  far  term  (late  1980's),  as  more  of  the  DCS  assets  become 
digital,  DM  will  prove  to  be  more  advantageous  then  PCM  because  of 
its  higher  capacity. 

e.  Tandem  Performance.  This  is  a  measure  of  the  system's 
ability  to  transfer  information  from  one  subscriber  to  another  without 
introducing  appreciable  errors.  For  previous  analyses  it  was  assumed 
that  the  transmission  media  and  switching  equipment  would  introduce 

an  error  rate  which  remains  constant  for  both  alternatives.  Alternative 
I  would  introduce  the  least  signal  degradation  in  a  tandem  A/D 
environment. 

f.  Technical  Risk.  Complexity  of  new  developments  and  hardware 
modifications  is  next  considered.  Both  alternatives  are  rated 

equal  in  this  regard,  as  equipment  has  been  developed  by  commercial 
manufacturers  which  can  be  used,  with  slight  modifications,  in  the  DCS. 

g.  Cost.  This  measure  considers  the  cost  of  equipment  developments 
and  modifications  as  well  as  that  of  logistical  support  factors.  Since 
alternative  II  involves  the  modification  of  more  equipment  than 
alternative  I,  it  will  have  a  higher  development  cost  and  may  have 

a  higher  logistics  support  cost. 

h.  Security.  Because  DM  has  a  higher  capacity  then  PCM, 
more  subscribers  can  be  converted  to  digital,  which  in  turn  can  be 
encrypted.  Hence,  DM  has  a  higher  potential  than  PCM  with  respect 
to  providing  security. 

i.  Maintainability.  The  ability  to  detect  and  correct  failures 
in  a  given  alternative  equipment  configuration  constitutes  this 
measure.  Maintainability  is  primarily  a  function  of  equipment 
complexity  and  sophistication.  Alternative  II  will  be  more  difficult 
to  maintain  than  alternative  I  because  of  the  additional  DM  multiplex 
equipment. 


j.  Survi vabi 1 i ty .  The  ability  of  equipment  to  perform  in  a 
degraded  mode  as  might  be  associated  with  a  war-time  environment, 


particularly  nuclear  conflict,  has  a  direct  impact  on  system 
survivability.  The  increased  channel  capacity  provided  by  DM  and 
its  higher  tolerance  to  transmission  errors  than  PCM  would  allow  a 
more  graceful  system  degradation  as  the  amount  of  traffic  increases, 
due  to  circuit  rerouting  around  the  damaged  parts  of  the  system. 

k.  Manpower  Skill  Level.  This  measure  is  concerned  with  the 
number  and  s k ill  level  of  personnel  required  to  operate  and  maintain 
equipment  associated  with  each  alternative.  This  measure  is  also 
primarily  a  function  of  equipment  complexity  and  sophistication. 
Alternative  I  would  have  the  lowest  manpower  requirements  because  no 
additional  O&M  personnel  are  involved.  Alternative  II, while  probably 
not  requiring  additional  personnel,  would  require  some  additional 
training  for  the  DM  equipment.  Therefore,  alternative  I  is  given  a 
higher  rating  than  alternative  II. 

7.  SUMMARY  OF  ASSESSMENT 

The  results  of  each  assessment  category  have  been  summarized 
in  the  Table  4-VI  along  with  the  calculation  of  an  overall  figure  of 
merit  for  each  alternative.  It  was  found  that  alternative  I,  the  PCM 
digitization  strategy,  has  a  higher  figure  of  merit  than  alternative 
II,  the  combined  PCM,  DM  alternative.  In  the  future,  however,  the 
advantages  of  DM  may  outweigh  those  of  PCM,  especially  as  the  DCS 
employs  more  digital  transmission  and  switching. 
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TABLE  4-  VI.  ASSESSKr  ‘UTEPNATIVl 


TOTA! 


V.  DCS  ENCRYPTION 


To  secure  sensitive  information  transmitted  in  the  DCS,  encryption 
of  lines  and  trunks,  in  both  backbone  and  access  areas,  can  be  expected. 
The  backbone  network  will  be  encrypted  in  conjunction  with  the  multi¬ 
plexing  hierarchy  of  DRAMA  [13].  Encryption  in  the  access  area  may 
take  the  form  of  end-to-end  security,  or  an  enclave  encryption  strategy, 
or  both. 

1.  CURRENT  STRATEGY 

DCA  plans  currently  have  specified  an  end-to-end  access  encryption 
concept  which  calls  for  the  implementation  of  digital  secure  voice 
terminals  (DSVT)  homed  on  a  digital  access  area  exchange  (DAX)  switch 
which  will  be  unmanned  and  will  contain  no  security  equipments.  It  is 
anticipated  that  each  secure  subscriber  will  either  have  his  own  secure 
terminal  or  will  be  connected  to  the  terminal  by  an  extension  device. 

Up  to  six  extensions  per  DSVT  will  be  possible. 

The  main  issue  to  be  considered  is  what  other  encryption  strategies, 
in  addition  to  the  current  strategy,  could  be  applied  to  DCS  subscribers 
in  the  access  area.  This  issue  is  a  function  of  type  and  number  of 
subscribers  and  the  environment  in  which  they  exist. 

2.  ENCLAVES 

An  enclave,  as  used  in  this  report,  is  defined  as  a 
physically  contained  area,  such  as  a  building,  in  which  a  body  of 
subscribers  is  located.  An  example  of  an  enclave  is  the  Defense 
Communication  Engineering  Center  (DCEC)  building.  A  secure  enclave 
is  an  area  to  which  some  measure  of  physical,  and  possibly  electronic 
security  has  been  provided.  The  National  Security  Agency  (NSA) 
headquarters  is  such  an  example. 

DCS  subscribers  resident  in  enclaves  that  are  secure,  or  capable 
of  being  secured,  are  candidates  for  enclave  encryption.  The  encryption 
may  include  line  concentrators,  multiplexers,  and  secure  private 
branch  exchanges.  The  existence  of  enclaves,  raises  the  possibility 
of  obtaining  authorization  to  pass  classified  information  over  local 
loops  within  the  enclave.  Secure  communications  between  the  enclave 
and  the  network  would  be  established  through  an  interface  device  defined 
as  part  of  any  encryption  strategy. 

3.  SYSTEM  ISSUES 

There  are  four  key  system  issues  that  affect  the  establishment  of 
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communications  security  in  the  access  area.  These  are:  the  environment 
in  which  secure  subscribers  exist,  including  any  physical  security;  COMSEC 
techniques;  timing  and  synchronization  strategies;  and  the  cost  of 
securing  the  subscribers. 

a.  Envi ronment.  Environmental  considerations  include  the  location 
of  subscribers  desiring  security,  the  level  of  physical  security  required, 
the  potential  for  secure  enclaves,  and  the  possible  interconnection  of 
enclaves . 

Subscriber  location  implies  not  only  geographic  location,  but 
also  location  in  relation  to  other  subscribers.  For  example,  the 
candidate  backbone  switches  for  overseas  and  CONUS  deployment  are 
markedly  different.  Overseas,  the  backbone  switch  will  be  RED/BLACK 
and  will  be  capable  of  terminating  approved  (RED-analog)  calls.  Such 
calls  would  be  transmitted  on  approved,  physically  secure,  transmission 
lines.  In  CONUS,  the  switch  will  be  BLACK,  and  will  not  terminate  this 
type  of  call.  All  calls  traversing  such  a  switch  will  be  either  those 
not  requiring  security  or  those  encrypted,  on  a  call-by-call  basis,  in 
the  access  area. 

The  subscribers'  location  with  respect  to  other  subscribers  impacts 
the  alternatives  that  can  be  used  to  secure  his  calls.  For  example, 
a  user  who  is  isolated  from  a  body  of  subscribers  may  require  special 
provisions  for  call  security,  such  as  a  DSVT  or  an  approved  line,  versus 
a  body  of  subscribers  that  may  reside  in  an  enclave  and  can  be  secured 
using  an  alternative  designed  for  secure  enclaves. 

Physical  security  is  an  importar  part  of  the  environment.  For 
example,  both  DCEC  and  NSA  Headqua'  s  are  secure  enclaves.  Each  of 
these  enclaves  has  different  physicu.  security  requirements.  At  DCEC, 
there  does  not  appear  to  be  the  need  for  fences  and  special  guards  as 
is  the  case  of  NSA.  In  addition,  the  Pentagon  requires  that  transmission 
lines,  terminating  secure  subscribers,  and  their  associated  main  terminals 
be  encased  in  intrusion  resistant  conduit  for  security  purposes.  This 
may  not  be  necessary  for  secure  enclaves  such  as  DCEC.  Overseas,  secure 
enclaves  may  require  special  provisions  such  as  fencing  and  periodic 
guard  inspection.  However,  such  provisions  have  not  yet  been  determined 
for  the  CONUS  or  overseas. 

The  potential  for  secure  enclaves  exists  in  the  DCS.  For  example, 
there  are  groups  of  subscribers  on  military  bases  who  require  call 
security  and  satisfy  the  enclave  definition.  The  potential  for  setting 
up  a  secure  enclave  to  provide  the  requisite  security  determines  the 
applicability  of  the  concept.  This  does  not  imply  that  failure  of  an 
enclave  application  obviates  securing  their  calls.  There  are  other 
schemes  capable  of  providing  needed  call  security,  such  as  the  current 
DCS  strategy  previously  mentioned. 
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Military  bases  also  provide  an  example  where  more  than  one 
enclave  may  exist  in  a  local  area.  Therefore,  there  is  the  potential 
for  interconnecting  these  enclaves  to  form  a  subnetwork  within  the 
DCS.  Such  an  interconnection  is  envisioned  for  the  current  DCS 
strategy. 

b.  COMSEC  Techniques.  The  COMSEC  techniques  to  be  used  in  the 
DCS  encryption  strategy  will  not  be  discussed  in  this  report  but  are 
available  in  [14]. 

c.  Timing  and  Synchronization.  Synchronous  digital  terminals 
homed  on  an  access  area  switch  will  require  timing.  This  timing  can  be 
obtained  from  an  access  area  switch  (AAS)  to  which  the  terminal  is 
homed.  If  the  terminal  operates  in  an  asynchronous  manner,  it  can 
generate  its  own  timing.  The  AAS  will  also  require  timing  for  its 
operation.  This  timing  can  be  derived  from  backbone  switch  connections 
in  a  master-slave  arrangement  or  can  be  provided  by  its  own  internal 
clock,  among  others  [15].  Access  area  synchronizat ion  is  discussed  in 
section  VII. 

d.  Security  Costs.  As  mentioned,  the  environment  in  which  secure 
subscribers  exist  is  a  major  system  issue.  This  issue  impacts  the 
cost  of  providing  the  requisite  access  security  in  terms  of  the 
equipment  needed  and  the  level  of  physical  security  required.  Cost 
implications  are  discussed  in  section  V-6. 

4.  SUBSCRIBER  REQUIREMENTS 

In  response  to  a  request  by  the  Director,  DCA,  the  JCS  requested 
each  MILDEP,  Unified/Specified  Command,  and  DoD  Agency  to  prepare  a 
list  of  proposed  secure  voice  subscribers  to  be  satisfied  by  the 
DCA  Secure  Voice  program,  AUTOSEVOCOM  II.  These  lists  were  to  be 
based  solely  on  mission  and  operational  security  considerations. 

These  listings  are  discussed  in  reference  [16],  and  are  also  given 
here  as  background  for  subsequent  discussion  of  alternatives  for 
providing  access  area  security. 

a.  Distribution  by  Theater.  Table  5-1  shows  the  subscribe  s 
distributed  by  theater  of  operation.  The  entries  reflect  requirements 
for  terminals,  extensions,  and  protected  wire  extensions.  The  protected 
wire  extensions  range  from  1  to  over  4000.  At  the  low  end  of  this  scale, 
requirements  are  interpreted  as  extensions  from  a  secure  voice  terminal. 
At  the  medium  and  higher  end,  the  requirements  reflect  a  need  for 

a  RED  type  distribution  system. 

b.  Distribution  by  Major  Initiating  Authority,  The  distribution  of 
user  requirements  by  major  submitting  authority  is  given  in  Table  5- 1 1 , 
from  a  breakout  of  the  entries  in  Table  5-1.  This  table  and  other 
breakouts  can  be  used  to  project  the  voice  traffic  demand  represented 

by  the  approved  subscriber  list  [16] 
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TABLE  5-1 1  -  AUTOSEVOCOM  II  SUBSCRIBER  SUBMISSIONS  BY  MAJOR  INITIATING  AUTHORITY 
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c.  Distribution  by  Functional  Category.  A  requirements  breakout 
by  functional  category  is  given  in  Table  5- III.  It  is  important  to 
note  that  the  first  three  entries  constitute  the  majority  of  the 
requirements  independent  of  the  theater  of  operation. 

It  cannot  be  determined  from  these  tables  alone  which  subscribers 
require  secure  terminals  and  which  require  only  extensions  off  the 
terminal.  Such  a  determination  would  require  in-depth  knowledge 
of  the  environment  in  which  they  exist.  This  environmental  knowledge 
would  also  be  necessary  before  any  potential  enclaves  could  be  addressed. 

5.  CONSIDERED  ENCRYPTION  ALTERNATIVES 

Alternatives  for  encryption  in  the  access  area  cover  a  wide 
range;  however,  those  considered  here  are  but  a  subset  of  a  much 
larger  set  that  could  be  studied.  Constraints  imposed  by  present 
DCS  programs  for  transmission  and  switching  have  been  considered  in 
the  formulation  of  these  alternatives.  Specifically,  the  alternatives 
to  be  considered  include:  End-to-End  security  (alternative  I);  A/D 
conversion  with  concentration  in  the  access  area  (alternative  II); 
and  PBX-to-PBX  Security  (alternative  III).  It  can  be  seen  that  both 
alternatives  II  and  III  are  concerned  with  enclave  encryption,  where 
the  enclave  may  be  nothing  more  than  a  secure  room,  and  that 
alternative  I  is  concerned  with  encryption  at  the  subscriber's  end 
instrument.  Figures  5-1  through  5-3  conceptually  show  the  alternatives. 
Mixes  of  both  analog  and  digital  subscribers  are  assumed  where  appropriate. 

a.  End-to-End  Encryption 

(1)  Definition.  This  alternative  presumes  that  signal 
encryption  is  provided  down  to  the  subscriber  end  instrument.  Current 
DCS  programs  have  specified  a  DSVT  with  up  to  six  extensions  for  each 
instrument.  This  alternative  is  also  characterized  by  a  digital 
access  switch.  A  DAX  has  been  specified  for  this  function. 

It  will  accept  both  secure  and  nonsecure  digital  traffic,  and  will 
be  connected  directly  to  a  tech  control  and  backbone  switch.  DAX's 
will  have  the  capability  of  being  interconnected.  Because  the  DSVT 
will  A/D  convert  and  encrypt  analog  voice,  the  encryption  being 
optional  and  obviated  for  nonsecure  calls,  there  is  no  need  for 
encryption  on  the  transmission  lines  between  the  DAX  and  the  backbone 
switch. 


(2)  Advantages.  The  major  advantage  of  this  alternative 
from  a  systems  viewpoint  is  that  encryption  is  provided  end-to-end. 
Thus  the  originating  encrypted  stream  will  never  need  to  be  decrypted 
anywhere  in  the  network.  Only  at  the  destination  DSVT  will  decryption 
result.  This  alternative  is  independent  of  the  environment  in  which 
secure  subscribers  exist,  provided  physical  security  for  the  DSVT  is 
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TABLE  5- 1 1 1 .  DISTRIBUTION  OF  AUTOSEVOCOM  II  SUBSCRIBER  SUBMISSIONS  BY 

FUNCTIONAL  CATFGORV 
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Figure  5-1.  End-to-End  Security  (Alternative  I) 


ACCESS  AREA  TRANSMISSION 


Figure  5-3.  PBX-to-PBX  Security  (Alternative  III) 
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available.  This  includes  application  to  isolated  subscribers  and  to 
enclaves  whether  secure  or  nonsecure.  That  a  DSVT  can  have  as  many 
as  six  extensions  is  key  factor  because  the  subscriber  population  will  not 
require  one  DSVT  per  subscriber.  Rather,  several  subscribers  can 
share  a  DSVT,  thereby  reducing  initial  investment  and  operation  and 
maintenance  costs.  This  will  result  in  a  smaller  number  of  terminations 
required  of  the  DAX,  further  reducing  costs  as  compared  to  a  DSVT  per 
subscriber. 

(3)  Disadvantages.  The  alternative  is  characterized  by  one 
major  system  disadvantage.  It  does  not  allow  for  the  DAX  to  accept  any 
subscriber  transmission  signals  that  are  not  DSVT  derived.  This 
precludes  the  use  of  the  DAX  for  any  purpose  other  than  processing 
DSVT  originated  or  terminated  traffic.  It  will  be  possible  to  inter¬ 
connect  DAX's,  but  only  DSVT  derived  traffic  will  be  carried  among  them. 

b.  Bulk  Encryption 

(1)  Defini tion.  This  alternative,  as  depicted  in  Figure  5-2, 
is  characterized  by  encryption  of  a  given  number  of  subscribers,  either 
digital  O'"  analog  in  format  Analog  subscribers  would  be  converted  to 
a  digital  equivalent  and  concentrated  before  being  encrypted.  Digital 
subscribers  would  be  concentrated  before  encryption.  The  digital 
stream  would  be  bulk  encrypted  in  the  enclave  before  entering  the 
transmission  subsystem  at  some  nominal  rate.  At  the  switch  side  of  the 
transmission  subsystem,  the  streams  would  be  decrypted  and  demultiplexed 
to  baseband.  These  resulting  digital  streams  would  be  directly  input 

to  the  switch  if  they  are  bit  rate  compatible  with  the  switch.  If 
they  are  not,  a  code  conversion  algorithm  would  be  required  to  establish 
the  compatibility. 

Figure  5-2  also  shows  an  approved  analog  access  line  that  is 
physically  secured,  rather  than  electronical ly  secured.  Inputs  to 
the  multiplex  would  be  analog  and  would  remain  analog.  At  the 
backbone  switch  end  of  the  transmission  subsystem,  the  transmitted 
stream  would  be  multiplexed  and  input  directly  to  the  analog  part 
of  the  backbone  switch,  presuming  that  the  switch  is  capable  of 
accepting  analog  inputs.  The  technical  control  facility  associated 
with  the  AN/TTC-39  switch  will  have  provisions  for  approvea  access 
lines.  However,  at  present  there  are  no  known  DCS  requirements 
to  terminate  RED  analog  calls  at  AN/TTC-39  switches  [16]. 

(2)  Advantages.  This  alternative  is  independent  of  traffic 
type  and  mix,  which  is  not  true  of  alternative  I.  Concentration  can  be 
employed  such  that  entry  into  the  transmission  can  be  made  through  a 
multiplexer  as  shown  in  alternatives  I  and  II  of  the  digitization 
strategy  (section  IV).  This  alternative  does  not  require  an  access 
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switch  for  its  operation.  Also,  if  subscribers  were  located  close  to 
the  switch,  they  would  be  brought  into  the  network  on  an  approved  access 
line. 


(3)  Disadvantages .  This  alternative  has  several  major  system 
implications.  For  traffic  distribution  at  the  backbone  switch,  the 
bulk  encrypted  lines  must  be  decrypted  and  demultiplexed.  This  would 
add  a  new  dimension  to  the  transmission  multiplex  hierarchy  planned  for 
the  transitional  period.  Presently,  there  are  no  DCS  transmission 
programs  to  decrypt/demultiplex  bulk  encrypted  access  lines.  If  the 
bulk  encrypted  access  lines  were  input  to  the  transmission  subsystem, 
say  at  the  1.544  Mb/s  rate  of  the  DRAMA  hierarchy,  there  would  be  the 
problem  of  encryption  imbedding  that  is  related  to  dynamic  communica¬ 
tions  stability,  which  will  be  discussed  in  section  VII.  Also,  the 
decrypted,  demultiplexed  streams  would  enter  the  backbone  switch  in 
the  clear  (RED  calls).  This  would  also  be  true  for  every  switch  in 
the  path  that  the  call  must  traverse  on  the  way  to  its  destination. 

These  RED  calls  would  be  encrypted  between  switches.  While  this  is 
not  a  major  disadvantage  for  overseas  deployment,  compared  to  alternative 

I,  it  would  be  impossible  for  CONUS  switches,  which  will  be  BLACK  and 
not  capable  of  processing  RED  analog  calls.  Hence,  this  alternative  is 
obviated  for  application  in  CONUS  access  areas.  The  only  possible 
exception  to  this  would  be  cases  where  the  bulk  encrypted  lines  are 
destined  for  a  single  location  and  hence,  do  not  require  switching 
or  adding  and  dropping  of  individual  subscribers.  Finally,  as  noted 
previously,  if  the  bulk  encrypted  streams  are  not  bit  rate  compatible 
with  the  backbone  switch  to  which  they  are  homed,  a  code  conversion 
must  result.  For  example,  if  a  CY-104  were  used  as  the  A/D  multiplexer- 
encryption  device  to  provide  bulk  encryption,  each  subscriber  would  be 
A/D  converted  to  64  kb/s.  This  rate,  however,  is  not  compatible  with 
the  basic  rate  structures  acceptable  to  the  AN/TTC-39  switch.  This 
would  entail  a  code  conversion  from  PCM  to  a  16  or  32  kb/s  code  without 
going  through  any  D/A-A/D  conversion  pair.  Unly  then  could  tne 
individual  streams  be  switched. 

c.  PBX-to-PBX  Encryption 

(1)  Definition.  This  security  concept  is  characterized  by  a 
RED/BLACK  access  switch  which  provides  both  A/D  conversion  and 
encryption  functions.  As  discussed  in  reference  [17],  it  is  a 
technically  feasible  approach  to  securing  certain  subscribers,  but 
one  which  appears  to  have  application  only  in  secure  enclaves. 

The  concept,  as  depicted  by  Figure  5-3  in  an  enclave  environment, 
allows  for  both  analog  and  digital  traffic  to  be  input  to  the  switch. 
Analog  traffic  would  be  A/D  converted  at  the  switch.  Those  subscribers 
requiring  security  would  have  their  communications  secured  at  the  switch, 
the  encryption  equipments  being  resident  and  pooled  at  the  switch. 
Subscriber  access  lines  between  terminals  an>  th>_  switch  would  be 
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analog,  except  where  digital  terminals  exist  such  as  DSVT's  and  data 
terminals.  In  essence,  this  alternative  emulates  alternative  I,  except 
that  COMSEC  has  been  transferred  from  the  subscriber  terminal  to  the 
secure  PBX. 

This  concept  allows  for  intra  area  and  interarea  communications, 
the  interarea  being  divided  into  the  backbone  area  and  other  access 
areas.  In  this  concept,  the  action  taken  by  the  PBX  on  subscriber 
calls  as  a  function  of  destination  is  given  in  Table  5- I V . 

(2)  Advantages.  In  this  alternative,  the  secure  PBX  will 
accept  both  analog  and  digital  traffic,  where  the  digital  traffic  may 
be  originated,  for  example,  by  DSVT's.  As  in  alternative  I,  encryption 
would  be  on  a  call-by-call  basis.  Therefore,  no  decryption  would  be 
needed  anywhere  in  the  network  except  at  the  destination  subscriber’s 
PBX  or  terminal.  This  alternative  would  allow  cornmuni cation  between 

a  homed  subscriber  and  distant  DSVT's  by  using  DSVT-type  COMSEC  equip¬ 
ments,  thereby  facilitating  interoperation  with  alternative  I.  COMSEC 
equipments  would  be  pooled  at  the  secure  PBX  and  allocated  on  as- 
needed  basis.  This  would  reduce  COMSEC  costs  compared  with  alternative 
I,  which  deploys  a  predetermined  number  of  secure  terminals. 

(3)  Disadvantages.  Application  of  this  alternative  is 
environment-dependent,  and  is  limited  to  secure  enclaves.  Hence,  both 
physical  security,  and  operation  and  maintenance  considerations  are 
impacted.  Physical  security  for  this  alternative  depends  explicitly 
on  such  factors  as  requirements  to  secure  the  analog  access  lines 
between  the  subscriber  terminal  and  the  secure  PBX,  periodic 
surveillance  of  these  lines,  and  external  enclave  protection  including 
fencing  and  manpower.  If  the  secure  PBX  requires  manning,  operation 
and  maintenance  factors  will  seriously  escalate  the  cost  for  this 
alternative.  However,  these  depend  on  the  level  of  security  provided 

the  enclave,  and  whether  the  COMSEC  equipments  can  themselves  be  adequately 
secured  within  the  enclave  confines.  Communications  are  not  end-to-end 
secured  but  rather  PBX-to-PBX,  or  PBX- to-called  subscriber  secured. 

Secure  communications  are  therefore  in  the  clear  between  the 
subscriber  analog  terminal  and  the  secure  PBX.  This  is  a  disadvantage 
when  compared  to  alternative  I. 

6.  COST  CONSIDERATIONS 

The  costs  associated  with  the  three  alternatives  include 
equipment,  0  and  M,  and  physical  security.  The  equipment  costs  are  those 
for  secure  terminals,  A/D  and  crypto  devices,  access  switches,  backbone 
access  lines  and  protected  wire  distribution. 

a.  Assumpti ons .  Certain  basic  assumptions  have  been  made  for  the 
costing  analyses  of  the  alternatives.  These  are  needed  because  of 
incomplete  knowledge  of  the  existing  communications  environment. 
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5-  IV.  PBX  ACTION  ON  SUBSCRIBER  CALLS 


Subscriber 

Traffic 

Destination 

PBX  Action 

Intra  area 

* 

Analog  I/O,  no  A/D 

Non-Secure 

Intra  area 

Analog  input,  A/D, 

1 

No  COMSEC 

Intra  area  Analog  I/O,  no  A/D, 

No  COMSEC 

Secure 

Intra  area  Analog  input,  A/D, 

pooled  COMSEC,  KDC 
key  acquisition, 
key  storage 
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Specifically,  in  the  initial  cost  comparison  of  alternatives  I  and 
II,  physical  security  requirements  have  been  assumed  to  be  the  same. 

However,  a  parametric  analysis  is  subsequently  given  to  show  the 
factor  increase  in  the  security  cost  of  alternative  III  as  compared 
to  alternative  I,  since  it  is  very  likely  that  physical  security  costs 
will  be  greater  for  alternative  III.  These  costs  must  be  considered 
on  an  implementation  case-by-case  basis.  Access  line  costs  between 
the  access  switch  and  associated  backbone  switch  have  not  been 
considered. 

Equipment  cost  factors  are  based  on  DCEC  cost  estimates  and 
are  discussed  in  detail  in  reference  [18],  with  the  exception  of 
Alternative  II  equipments.  For  alternative  II,  it  is  assumed  that 
an  existing  CY-104  having  24  individual  A/D,  multiplexing  and 
encryption  capabilities,  can  satisfy  bulk  encryption  needs.  It  is 
further  assumed  that  redundancy  is  required  and  that  a  similar 
device  will  exist  at  the  backbone  switch  due  to  the  lack  of  code 
converters  and  because  provision  has  not  been  made  for  terminating 
these  subscribers  in  present  DCS  programs. 

Because  there  are  no  known  DCS  requirements  for  approved 
subscriber  lines  and  because  transitional  DCS  CONUS  switches 
have  no  provision  for  approved  lines,  this  part  of  alternative  II  was 
not  costed. 

Table  5-V  shows  the  equipment  specifics  and  the  0  and  11  factors. 
Physical  security  costs  have  not  been  considered. 

Since  the  costs  associated  with  alternative  III  are  based  on 
pooled  equipments,  a  statistical  characterization  is  used. 

For  the  analyses  it  is  assumed  that  subscribers  originate  .2  calls 
per  busy  hour  with  a  holding  of  5  minutes,  and  a  1"  switch  blocking 
probability. 

b.  Cost  Tradeoffs.  Figure  5-4  shows  the  results  of  the  costing 
analysis  where  it  has  been  assumed  that  the  secure  PBX,  for  alternative  III, 

is  unmanned.  Encryption  requirements  are  assumed  to  have  been 
physically  secured  within  the  switch  which  is  imbedded  within  the 
enclave.  The  curves  in  Figure  5-4  are  a  function  of  the  number 
of  DSVT  extensions  for  alternative  I,  and  the  number  of  analog  phones 
attached  to  the  same  address  number  for  alternative  III. 

Costs  for  bulk  encryption  are  constant  over  the  full  range  of 
subscribers.  This  results  wholly  from  the  traffic  ard  blocking 
statistics  which  indicate  that  one  secure  terminal  can  service  up 
to  145  subscribers  with  one  channel  being  held  as  a  spare. 
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TEN-YEAR  LIFE  CYCLE  COST  (XIO  ) 


SUBSCRIBERS  (Total  Population) 


Figure  5-4.  Ten-Year  Life  Cycle  Cost  Versus  Subscribers-Unmanned  PBX 


It  can  be  inferred  from  Figure  5-4  that  there  are  subscriber 
regions  in  which  one  alternative  dominates  others.  It  is  apparent 
that  bulk  encryption  has  significant  advantages  over  DSVT  or  secure 
PBX  concepts  for  the  full  range  of  subscribers.  However,  as  previously 
mentioned,  there  are  operational  difficulties  with  bulk  encryption  in 
securing  the  information  in  the  backbone  area. 

c.  Operation  and  Maintenance.  Of  the  cost  factors  involved.  Oand  M 
produces  a  significant  change  in  the  life  cycle  costs.  For  example,  if 
all  assumptions  remain  unchanged  except  the  manning  assumption  for 
alternative  III,  significant  differences  in  the  application  of  the 
alternatives  to  specific  subscriber  population  will  result.  Figure  5-5 
shows  this  manning  change  cost  effect  to  alternative  III.  With' two 
extensions  chosen  as  an  illustrative  example,  the  results  of  this 
figure  indicate  that  for  less  than  approximately  54  subscribers,  the 
DSVT  concept  is  preferred  over  the  secure  PBX  concept.  For  alternatives 
I  and  II,  0  and  M  is  assumed  unchanged.  The  cost  increase  is  significant 
when  compared  to  the  previous  unmanned  case  in  which  the  secure  PBX 
alternative  was  always  preferred  for  two  extensions. 

d*  Physical  Security.  The  cost  associated  with  physical  security 
1S  a1so  significant]  Forthe  previous  analyses  presented  it  was  assumed 
that  physical  security  for  both  alternatives  I  and  II  was  identical. 
However,  for  alternative  III,  physical  security  may  be  required 
depending  upon  the  environment,  because  the  analog  subscriber  lines  mav 
need  physical  protection  or  because  security  external  to  the  access 
area  might  be  necessary.  The  associated  costs  for  the  alternatives 
would  be  greatly  affected. 

As  an  example,  consider  2  subscribers  on  the  average  per 
terminal,  and  a  population  of  20  subscribers.  From  Figures  5-4  and 
5-5,  the  cost  for  alternative  I  is  D  =  $322K;  for  alternative  III, 
the  costs  are  Eo  =  $257K  for  the  unmanned  case,  and  E  =  S452k  for 
the  manned  case.  These  values  are  used  as  a  base  for°Fioure  3-6  which 
shows  the  effects  of  increasing  the  physical  security  ccst  of  alternative 
MI  above  that  of  alternative  I.  The  initial  cost  for  physical  security 
common  to  both  is  indicated  on  the  figure.  Alternative  III  costs  are 
found  by  multiplying  the  ordinate  factor,  N,  by  the  sum  of  D  and  the 
initial  physical  security  cost.  0 

7.  DISCUSSION 

Of  the  key  issues  discussed,  the  environment  appears  to  have  the 

s®no^s  impact  on  the  application  of  the  alternatives  to  securinq 
DCS  subscribers.  As  noted,  alternative  I  is  environment  independent, 
whereas  alternative  III  depends  explicitly  on  the  environment,  mainly 
as  a  function  of  physical  security.  DC A  has  no  stated  requirements 
for  alternative  II;  hence,  it  is  not  considered  a  likely  candidate 
for  inclusion  in  the  DCS. 
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TEN-YEAR  LIFECYCLE  COST  (X10°) 


SUBSCRIBERS  (Total  Population) 

Figure  5-^". Ten-Year  Life  Cycle  Costs  Versus  Subscriber-Manned  Secure  PBX 
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Increased  Physical  Security  Costs  (Ten-Year  Cost)  For  Alternative  III 


The  data  submitted  in  Tables  5-1  through  5- 1 1 1  support  the 
conclusion  that  both  alternatives  I  and  III  can  find  DCS  application, 
but  present  programs  do  not  include  any  provision  for  interoperation. 


The  cost  analysis,  though  specific  as  far  as  assumed  statistics 
are  concerned,  has  shown  that  there  are  subscribers  populations  for 
which  alternative  I  is  preferred  over  alternative  III,  and  conversely 
It  further  demonstrates  that  there  is  potential  application  for  both 
alternatives. 
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VI.  SOFTWARE  COST  MINIMIZATION 


1 .  THE  TREND  OF  SOFTWARE  COST 

In  recent  years  the  increased  use  of  computers  within  the  Defense 
Communications  System  has  caused  a  software  cost  explosion.  While 
state-of-the-art  advances  in  technology  have  kept  hardware  cost  down, 
costs  in  the  labor  intensive  area  of  software  are  rapidly  rising  to 
the  point  where  it  is  becoming  the  dominant  contributor  to  computer 
system  cost.  For  example,  software  cost  within  DoD  has  been  reported 
in  excess  of  $3  billion  per  year  [19].  For  the  Air  Force,  the  current 
software/hardware  ratio  of  total  automatic  data  processing  system  cost 
is  greater  than  65/35,  and  based  on  current  estimates  the  ratio  will 
swell  to  90/10  by  1985  [19].  The  increased  dependence  of  the  DCS 
on  computing  capability  and  the  continued  increase  in  the  ratio  of 
software  to  hardware  cost  emphasize  the  need  for  additional  effort  in 
the  area  of  software  cost  minimization. 

The  utilization  of  software  is  expected  to  increase  in  the  next 
decade.  For  example,  three  related  areas  of  development  that  presently 
require  software  support  are:  computer  security  mechanisms,  computer 
networking,  and  distributed  systems  built  from  microprocessors.  In 
order  to  harness  and  consolidate  the  potential  of  many  microprocessors 
or  computers  for  a  particular  effort  such  as  computer  networking,  their 
activities  must  be  coordinated  and  controlled  by  software  [20].  If 
such  a  processing  environment  is  expected  to  handle  classified  as 
well  as  unclassified  data,  then  additional  precautions  must  be 
taken  to  ensure  that  the  software  performs  specific  functions,  and 
under  no  conditions  does  it  perform  unexpectedly. 

The  intent  of  this  section,  is  to  examine  why  the  development 
cost  of  software  has  continued  to  increase  relative  to  hardware, 
identify  opportunities  for  a  reduction  in  the  cost  of  software 
production  and  maintenance,  and  recommend  the  action  necessary 
to  improve  the  quality  and  reduce  the  cost  of  software.  Furthermore, 
significant  changes  in  requirements  being  placed  on  software  are 
identified,  and  some  trends  occurring  in  software  development  in  the 
future  are  outlined.  It  is  hoped  that  this  section  may  serve  as  a 
catalyst  for  realistic  and  fruitful  action. 

a-  Factors  Influencing  Software  Cost  Estimation.  The  following 
are  factors  to  be  considered  in  estimating  cost: 

•  Number  of  Source  Instructions.  This  is  a  measure  of  the 
complexity  of  the  task.  A  major  problem  in  large  systems  is 
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the  increase  in  cost  per  instruction  as  the  number  of 
instructions  increases.  For  example,  one  study  [21] 
reported  that  the  development  rate  for  instructions  per 
hour  ranged  from  .33  to  .53  for  large  real-time  programs 
(programs  over  100,000  lines  of  code),  to  1.6  to  5  instructions 
per  hour  for  programs  from  5,000  to  20,000  instructions,  under 
similar  conditions. 

•  Source  Language  Programming.  The  time  required  to  develop  a 
program  using  assembly  language  has  been  reported  as  high  as 
twice  the  time  required  if  a  high  order  language  is  used  [22]. 

A  more  recent  study  [21]  involving  the  development  of  real-time 
systems  indicated  a  20%  reduction  in  total  development  effort 
through  the  use  of  a  higher  order  language.  Software  costs 
for  a  given  number  of  statements  tend  to  be  similar  whether 
the  program  is  written  in  a  high  order  language  or  assembly 
language.  Thus,  the  saving  is  a  direct  result  of  fewer 
statements  being  written  with  a  high  order  language.  High 
order  language  programming  also  tends  to  result  in  better 
programming  algorithms  and  easier  program  maintenance,  since 
the  programmer,  by  having  to  look  a'  fewer  instructions,  is 
able  to  group  a  large  portion  of  the  problem  and/or  understands 
the  problem  more  rapidly. 

•  Type  of  Application.  The  cost  for  real-time  application's  has 
been  estimated  as  much  as  five  times  greater  than  for  non-real¬ 
time  applications  [22].  The  communications  systems  development 
would  be  considered  a  real-time  application.  Personnel  from 
Bolt  Beranek  and  Newman,  Inc.,  during  a  meeting  held  at 

the  Defense  Communications  Engineering  Center  in  October  1976, 
estimated  that  executive  system  software  cost  is  approximately 
three  times  the  cost  of  compiler  language  software  on  a  per- 
instruction  basis.  Furthermore,  it  was  predicted  that 
communications  software  costs  are  approximately  three  times 
greater  than  executive  system  software  costs.  Another  study 
[21]  indicated  that  large  real-time  programs  required  four 
to  five  times  the  development  effort  necessary  for  support 
programs  such  as  loaders,  editors,  assemblers,  and  utility 
programs.  There  is  adequate  information  available  to  indicate 
a  significant  difference  in  the  effort  necessary  for  different 
types  of  applications. 

•  Participant's  Experience.  A  recent  study  [21]  concluded  that 
the  most  important  single  factor  which  determined  the  different 
development  rates  was  the  experience  level  of  the  designing 
programmers  and  supervisors.  In  fact,  development  times  may 

be  reduced  significantly  if  the  program  is  a  variant  of  a 
familiar  program. 
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•  Availability  of  Generalized  Support  Packages.  An  application 
which  can  utilize  a  support  package  such  as  a  generalized 
management  information  system  can  accrue  significant  cost 
reduction;  support  package  utilization  should  be  evaluated 
and  encouraged  in  appropriate  circumstances.  In  fact,  the 
availability  of  software  support  tools  has  been  recommended 
[23]  as  a  major  consideration  in  the  selection  of  a  vendor 
for  software  development.  Unfortunately,  many  support  tools 
are  both  language  and  machine  dependent. 

•  Size  and  Structure  of  the  Data  Base.  Software  that  retrieves 
and  utilizes  information  from  external  resources  such  as  data 
bases  costs  more  per  instruction  than  similar  programs  without 
data  interactions  [22],  The  processing  requirements  of 

data  must  be  considered  in  the  design  phase  so  that  proper 
checks  and  controls  are  implemented  to  avoid  unnecessary 
termination  of  processing  due  to  invalid  entries. 

•  Turnaround  Time.  Interacting  computing  facilities  can 
reduce  turnaround.  Current  estimates  [24]  indicate  at  least 
a  20/o  improvement  in  program  development  by  using  interactive 
computing  instead  of  batch  processing. 

•  Hardware  Constraints.  Hardware  procurement  frequently  precedes 
software  development.  If  the  hardware  is  improperly  sized  for 
the  job  or  if  the  size  of  the  job  expands,  attempts  are 
frequently  made  to  have  the  software  compensate  for  hardware 
inadequacy.  The  availability  of  different  hardware  configura¬ 
tions  through  computer  networking  should  enable  the  user  to 

make  better  procurement  decisions  by  allowing  software  development 
and  sizing  on  a  host  computer  prior  to  procurement  of  hardware. 

The  actual  delivery  date  of  hardware  may  be  less  crucial,  since 
considerable  development  and  testing  may  occur  within  the 
network  environment. 

t  Software  Production  Schedules.  An  unrealistically  foreshortened 
software  production  schedule  normally  results  in  significantly 
higher  project  cost,  provided  the  original  schedule  was  well 
planned  and  realistic  [21].  The  quality  of  the  product  suffers; 
hence,  the  maintenance  costs  are  increased.  Management  must 
consider  these  penalties  when  they  shorten  software  production 
schedules.  Current  studies  reveal  that  increasing  the 
staff  on  a  software  project  after  it  has  been  initiated 
frequently  extends  the  length  of  the  project  instead  of 
shortening  it.  Generally,  the  fewer  the  number  of  programmers, 
the  greater  the  productivity  per  programmer. 
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Expected  Quality  and  Reliability.  The  functional  capabilities 
expected  from  a  specific  software  module  dictate  the  expected 
quality  and  reliability.  For  example,  software  support  for 
systems  which  simultaneously  process  different  levels  of 
classified  material  must  be  certified.  The  intent  of 
certification  is  to  ensure  that  the  software  performs  as 
intended  and  does  nothing  more.  Based  on  the  current  trend, 
it  is  anticipated  that  eventually  this  certification  will 
require  that  the  code  is  proven  correct.  Regardless  of  the 
approach,  the  cost  of  such  software  will  include  additional 
expenditures  to  ensure  that  precautionary  measures  have 
been  taken  to  avoid  security  compromises. 

Development  Environment.  The  development  and  testing  of  software 
may  occur  in  an  environment  substantially  different  from  the 
planned  implementation  environment.  Some  companies  [21]  have 
improved  the  production  rate  from  25  instructions  per  hour  to 
40  instructions  per  hour  through  the  use  of  a  simulator.  In 
communications  systems,  simulation  is  difficult  because  of  the 
real-time  operating  environment.  Thus,  the  simulation  must 
in  many  cases  consider  the  relative  execution  time  of  routines. 

Stability  of  Requirements.  Studies  have  shown  that  more 
development  effort  is  spent  in  the  10  years  following 
implementation  than  during  the  initial  development  [21]. 

Changing  requirements  will  increase  the  life  cycle  cost  of 
software;  however,  proper  initial  planning  and  analysis  are 
essential  to  anticipate  such  changes  and  implement  them  in 
a  timely  and  inexpensive  manner. 

Personnel .  Probably  no  field  has  a  greater  variance  in  the 
ability  of  personnel  than  software  development;  studies  have 
shown  ratios  of  productivity  as  great  as  26  to  I  [24].  Further¬ 
more,  the  more  productive  people  tend  to  produce  the  more 
realiable  software.  Emphasis  should  be  placed  on  proper  selection 
and  retention  of  quality  people.  Personnel  are  the  most 
important  ingredient  in  determining  the  success  or  failure 
of  a  system  [21]. 

Development  Techniques.  Techniques  such  as  structured 
programming,  automated  aids,  and  chief  programmers  teams  have 
contributed  to  a  reduction  in  software  cost  [25,  21]. 

Appropriate  research  should  be  continued  to  develop,  identify 
and  provide  proven  methods  for  future  software  projects. 

Management  Involvement.  Management  must  have  a  high  deqree 
of  awareness  and  understanding  of  software  so  that  they  can 
initiate  changes  needed  to  lower  the  life  cycle  cost  of  software. 


Management  has  the  responsibility  and  the  opportunity  to 
make  a  significant  impact  on  the  software  cost. 

These  factors  are  frequently  used  in  the  estimation  of  software 
costs.  It  is  impossible  to  plan  effectively  and  develop  realistic 
costs  if  one  cannot  estimate  expenditures  for  software.  Although 
many  companies  [21,  22,  26]  have  developed  methods  to  estimate 
software  cost,  these  methods  tend  to  be  proprietary.  The  Government's 
problem  in  cost  estimation  is  increased  by  the  lack  of  available 
metrics.  In  regards  to  software,  the  term  metric  is  defined  as 
the  standard  which  is  a  measure  of  the  extent  to  which  a  module  of 
software,  or  a  system  containing  software,  possesses  and  exhibits  a 
certain  property  [27].  It  is  important  to  develop  metrics  that  can 
be  utilized  Ly  many  different  organizations.  For  example,  a  cost 
model  may  require  specific  inputs  that  describe  the  characteristics  of 
the  software,  and  if  organizations  intending  to  utilize  these  models 
do  not  have  the  proper  data  in  the  expected  units  of  measure,  then 
the  results  will  be  meaningless. 

There  is  a  need  for  additional  research  and/or  investigation 
into  the  development  of  appropriate  metrics  and  cost  models.  The 
Department  of  Defense  does  not  possess  the  capability  to  evaluate 
different  alternatives  that  require  an  accurate  estimation  of 
software  cost.  This  deficiency  is  not  caused  by  the  lack  of 
technological  knowledge;  rather  it  has  occurred  because  there 
is  a  need  to  develop  appropriate  cost  models  and  collect  the 
supporting  data. 

b.  Life  Cycle  Cost.  Software  costs  are  not  as  easy  to  identify 
and  isolate  as  hardware  costs.  A  hardware  component  has  a  fixed  initial 
cost  and  some  expected  maintenance  cost.  The  term  "design-to-cost"  is 
defined  as  the  process  utilizing  unit  cost  goals  as  thresholds  for 
managers  and  as  design  parameters  for  engineers.  This  concept  has 
been  reduced  to  practice  for  computing  hardware;  it  is  not  fully 
understood  for  software. 

The  initial  financial  commitments  for  software  are  small 
compared  to  total  commitment  (see  Figure  6-1).  Software  costs  include 
all  the  effort  involved  in  producing  and  maintaining  the  necessary 
executive,  support,  and  application  programs  and  their  documentation; 
well  defined  functional  specifications  should  also  be  included. 

Software  development  and  maintenance  can  be  represented  by  the 
following  steps: 

t  Establish  Performance  and  Design  Requirements 
t  Develop  Implementation  Concept  and  Test  Plan 
0  Develop  Interface  and  Data  Requirements  Specifications 
0  Create  Detail  Design  Specifications 
0  Complete  Coding  and  Debugging 
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Figure  6-1.  Composite  Software  Life  Cycle 


VI -6 


•  Develop  Software  Documentation 

•  Complete  System  Validation  Testing 

•  Document  Certification  and  Acceptance  Procedures 

•  Install  and  Check  Out  Operational  Configuration 

•  Maintain  and  Update  Existing  Software 

One  should  be  aware  that  statistics  currently  available  on 
the  cost  of  different  phases  of  the  life  cycle;  these  figures 
may  be  badly  distorted  [28]  in  that  some  of  the  largest  systems 
are  still  in  the  process  of  development.  Furthermore,  maintenance 
cost  will  increase  each  year  the  system  is  in  existence;  some  experts 
[21]  have  estimated  that  a  system  which  required  46'  of  the  life  cycle 
cost  for  maintenance  after  4  years  may  be  expected  to  approach  60  of 
the  life  cycle  cost  in  10  years.  A  summary  of  the  distribution  of  the 
development  cost  of  several  systems  is  shown  in  Table  6-1  [19]. 

The  interaction  between  different  phases  of  the  life  cycle  makes 
it  difficult  to  assess  the  impact  that  one  can  expect  from  improving 
the  performance  and/or  quality  of  the  effort  within  a  particular  phase. 
For  example,  errors  made  during  the  design  phase  may  not  be  identified 
until  the  maintenance  phase;  thus,  their  impact  on  cost  would  be 
reflected  in  the  cost  of  maintenance  (see  Figure  6-2).  Since  the 
design  and  maintenance  phases  represent  65'  of  the  total  cos;  (based 
on  today's  statistics)  and  are  attributed  with  more  than  80  of  the 
cost  caused  by  errors  [25],  they  should  be  the  primary  targets  for 
improvement.  Available  data  on  cost  of  detection  and  correction 
indicates  that  design  errors  cost  the  most  to  diagnose  and  fix 
[21,  25].  The  cost  of  detecting  and  resolving  a  software  error  after 
it  has  been  placed  into  service  is  thirty  times  larger  than  the  cost 
required  to  deduce  and  resolve  an  error  during  initial  reading  and 
review  of  code  [21].  It  has  been  reported  that  70  of  design  errors 
are  not  identified  until  after  development  is  completed.  Obviously, 
it  is  very  important  to  be  aware  of  the  impact  that  one  phase  can 
have  on  another  phase.  In  the  future  one  can  expect  an  additional 
phase  or  function,  proof  of  correctness  [29],  to  be  added  to  the 
life  cycle  of  software  where  the  software  must  be  exceedingly 
reliable.  Although  it  may  actually  be  hidden  in  the  coding  and 
debugging  phase,  it  should  change  the  distribution  of  cost  during  the 
life  cycle  of  the  software.  Furthermore,  there  are  many  functions 
such  as  documentation  that  affect  the  cost  of  maintenance;  it  is 
important  that  these  related  factors  be  evaluated  in  terms  of  total 
life  cycle  cost  and  not  just  their  impact  on  the  cost  associated 
with  a  particular  phase. 

2.  OPPORTUNITIES  FOR  REDUCTION  IN  SOFTWARE  COST 

Because  of  the  interaction  between  phases  of  the  life  cycle,  it 
is  not  clearly  evident  [21,  25]  from  the  available  analysis  where 
the  greatest  opportunities  exist  for  reducing  cost.  Furthermore, 
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TABLE  6-1.  BREAKDOWN  OF  DEVELOPMENT  COST  FOR  SELECTED  SYSTEMS 
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LOGIC  &  SYNTAX 
ERRORS  DURING 
MAINTENANCE 


MAINTENANCE 


'NOTE:  The  cost  required  to  detect  and  resolve  a  design  error  after 
it  has  been  placed  in  service  is  anproximately  thirty  times 
larger  than  cost  required  to  detect  and  resolve  such  a  bug 
durino  the  initial  development. 


Figure  6-2.  Life  Cycle  Cost  Attributed  to  Different  Types  of  Errors  in 
Development  and  Maintenance. 
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statistics  currently  available  on  the  cost  of  different  phases  of  the 
1 i f e  cycle  of  software  are  somewhat  deceptive  [28].  These  figures 
are  badly  distorted  in  that  some  of  the  largest  systems  are  still 
under  development,  whereas  those  in  maintenance  were  those  produced 
in  much  less  ambitious  times.  In  most  recent  systems,  one  can  expect 
the  operations  and  maintenance  cost  to  exceed  those  for  development 
and  acquisition  by  several  times  (see  Figure  6-3)  [28].  It  does 
appear  that  design  and  maintenance  are  certainly  two  phases  where  an 
improvement  could  produce  substantial  savings  (see  Table  6- 1 1 ) . 

Design  and  maintenance  costs  cannot  be  studied  by  themselves 
because  there  is  an  interdependency  between  all  of  the  phases  of 
life  cycle  software  cost.  For  example,  the  utilization  of  a  higher 
order  language  to  promote  transportability  of  valid  code  may  have  a 
significant  impact  on  maintenance  cost.  Since  software  is  expensive 
to  develop  and  the  same  capabilities  are  developed  for  many  systems 
(some  are  identical  systems)  it  would  appear  logical  to  maximize  the 
repeated  useability  of  software.  The  ability  to  achieve  this 
objective  has  failed  to  materialize  because  software  historically  has 
been  structured  to  the  architecture  of  the  particular  target  computer. 
However,  the  continued  increase  in  the  cost  of  computer  software, 
the  introduction  of  transportability  of  software  over  a  network,  and 
a  better  understanding  of  software  architecture  as  opposed  to  computer 
architecture  enhances  the  likelihood  of  success. 

Regardless  of  technical  expertise,  the  ultimate  responsibility 
for  the  high  cost  of  software  resides  with  management.  Management 
has  too  long  been  in  awe  of  the  "Computer  Revolution."  It  must  take 
the  necessary  action  to  control  software  projects.  The  first  step 
is  to  become  educated  in  the  principles  of  software  so  that  software 
development  and  maintenance  can  receive  the  equivalent  control  and 
scrutiny  given  hardware  [21,  23]. 

a.  Software  Design.  The  activities  that  are  actually 
considered  part  of  the  design  process  vary  depending  on  the 
reference  [2]].  Frequently  recognized  achievements  in  the  design 
process  are  the  following  [21,  25]: 

•  An  overall  functional  specification  describing  what  is  to 
be  performed. 

•  The  dependencies  between  each  major  function  and  the 
modules  which  are  expected  to  provide  the  functional  support. 

•  The  linkages  between  modules. 

•  A  "structured"  logic  flow  such  as  a  system  flow  chart. 

•  All  data  structures  and  their  corresponding  intended  usage, 
attributes,  access  method,  and  value  range. 
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SPECIFICATION  7 % 


Estimated  Distribution  of  Life  Cycle  Cost  for 
Systems  Currently  in  Development  [21],  [28], 


TABLE  6-1 1 .  AN  ATTAINABLE  GOAL  FOR  THE  REDUCTION  OF  COST 
IN  THE  LIFE  CYCLE  OF  SOFTWARE. 


Design 

Errors 


Logic  & 

SYNTAX 

Errors 


Maintenance 
Cost  Not 
Attributed 
Lo  Errors 


Present  Annual 
Cost 

(Millions) 

Percentage  of 
Reduction 

Yearly  Savings 
(Millions) 

1 ,200 

15% 

180 

90 

1 

25% 

22.5 

i 

210 

10% 

21 

1,500 

15% 

- -J 

223.5 

NOTE:  Cost  data  above  are  based  on  an  annual  cost  of  $3  billion. 
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•  Definition  of  all  data  inputs  to  each  segment  and  data  outputs. 

•  Test  plans  to  test  the  operation  of  each  module. 

(1)  Approaches  to  Software  Design.  The  design  process  is 
frequently  not  a  formalized  approach.  One  approach,  HIPO,  which  is 
described  in  this  section  has  been  successfully  used  in  the 
development  of  software  for  large  stored  program  controlled 
telephone  switching  machines  [25].  A  variety  of  approaches  have 
been  utilized  with  limited  success;  these  approaches  do  provide 
guidelines  and  are  certainly  better  than  undisciplined  approaches. 

Some  of  the  techniques  being  utilized  in  the  design  process  are  the 
following  [21,  30,  31]: 

•  Levels  of  abstraction,  as  defined  by  Dijkstra,  provide  a 
framework  for  clear  and  logical  system  design.  The  system 
is  conceived  as  a  hierarchy  of  abstract  levels.  The  lowest 
levels  are  closest  to  the  machine.  Each  level  supports  an 
important  abstraction;  levels  of  abstraction  is  a  useful 
specification  tool  because  it  allows  us  to  become  less 
dependent  on  "nonessential"  details  of  a  particular 
implementation  [30,  32]. 

•  A  top-down  development  process  in  which  the  higher  level 
module  is  given  as  a  program  specifying  the  flow  of  control 
among  certain  lower  level  functional  modules. 

•  Higher  Order  Software  is  a  formal  methodology  for  defining 
requirements  for  computer  based  systems  [30].  It  is  based 
on  six  axioms;  the  utilization  of  such  a  system  needs  the 
support  of  a  specification  language  and  corresponding 
software  tools.  This  approach  is  still  under  development. 

t  THREADS  is  a  requirements-oriented  methodology  that  defines 
a  system  in  terms  of  units  specifically  keyed  to  required 
system  capabilities.  This  system  was  developed  by  Computer 
Sciences  Corporation. 

•  HIPO  is  a  procedure  developed  by  IBM  [33].  The  objectives 
are  expressed  as  a  hierarchical  procedure  where  inputs  and 
the  corresponding  process  and  resulting  outputs  are  defined 
and  redefined  until  the  desired  level  of  detail  is  obtained. 

The  intermediate  stages  are  retained. 

Frequently  a  combination  of  different  techniques  is  utilized  in 
the  design  process.  Unfortunately,  the  importance  of  the  design 
phase  is  frequently  not  recognized.  While  these  approaches  or 
techniques  have  provided  some  improvement  in  the  design  process, 
there  is  still  an  urgent  need  for  additional  progress  in  design 
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techniques.  This  need  is  indicated  by  the  high  cost  of  errors  in 
system  design  and  the  failure  of  software  to  perform  its  intended 
function. 


(2)  Potential  for  Improvement  in  the  Design  Process.  There 
are  two  ways  to  approach  the  improvement  in  the  design  process: 

(1)  improve  the  current  techniques,  and  (2)  identify  new  techniques. 
Management  reviews  and  technical  "walk-throughs "  have  been  very  useful 
in  identifying  design  errors.  The  walk-through  is  a  formal  review 
technique  where  test  inputs  are  generated  and  "eyeballed"  through 
the  design  to  verify  its  accuracy  [21].  While  those  efforts  have  improved 
the  design,  too  often  the  specifications  are  not  consistent  with  the 
requirements.  Additional  research  is  recommended  to  improve  the 
approach  used  in  management  reviews  and  technical  walk-throughs. 

It  may  be  appropriate  to  develop  a  scenario  for  management  review  and 
actually  let  management  simulate  the  use  of  the  system  through  its 
outputs.  The  essential  content  and  format  of  a  scenario  for  such  a 
review  are  unknown.  Some  of  these  questions  will  be  formulated  and 
answered  in  a  current  effort,  "Study  of  Engineering  Practices  for 
Communications  Software". 

The  experience  level  of  personnel  is  considered  by  some 
experts  to  be  the  most  important  criterion  needed  to  ensure  successful 
development  of  software  [21].  Thus,  there  is  a  need  to  develop  a 
technique  for  recording  the  design  efforts  of  experienced  personnel 
so  that  this  information  can  be  identified  and  retrieved  for  review 
[34].  More  emphasis  has  been  placed  on  other  areas  such  as  proof  of 
correctness,  portability  of  programs,  and  languages  which  assume  the 
design  is  correct.  Yet,  the  errors  in  design  represent  approximately 
40%  of  the  life  cycle  cost;  it  appears  that  more  emphasis  needs  to  be 
placed  on  design.  It  may  be  possible  to  modularize  and  define  portions 
of  design  efforts  such  that  they  are  useful  in  future  efforts. 

-  There  is  a  real  need  to  be  able  to  verify  that  the  specifications 
are  consistent  with  the  user  requirements,  and  similarly,  the  computer 
programs  are  consistent  with  the  specifications.  For  example,  it 
would  seem  reasonable  to  prove  that  each  message  in  a  telecommunications 
system  has  been  delivered.  Some  research  is  being  done  to  prove 
that  security  policies  are  accurately  supported  by  the  system  [35]. 

This  effort  should  be  extended  to  include  the  proof  of  functional 
requirements . 

Design  flexibility  is  especially  important  in  regard  to  changes 
in  requirements,  particularly  those  occurring  after  a  system  is 
operational.  There  is  need  to  develop  a  methodology  that  would 
enable  a  design  to  be  described  and  certified  in  terms  of  functional 
capabilities.  It  would  be  a  logical  or  conceptual  design  which  could 
be  the  basis  for  the  mapping  of  real  software/hardware  components 
during  the  implementation  of  a  system.  The  usefulness  of  such  a 
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design  will  depend  on  the  guidance  and  insight  it  can  provide  for 
actual  implementations.  It  is  a  reasonable  approach  for  ensuring 
flexibility  in  design,  and  it  represents  an  initial  method  to  record 
the  design  efforts  of  experienced  personnel.  It  is  usually  described 
in  terms  of  abstract  entities  such  as  logical  processes  and  virtual 
entities.  DCEC  recently  completed  a  contract  that  studied  the 
development  of  a  logical  model  for  communications  software.  This 
contract  explored  the  feasibility  of  some  specific  rules  and  actually 
simulated  the  implementation  of  a  simple  model.  There  is  also  a 
need  to  develop  a  methodology  for  the  logical  design  and  integration 
of  hardware  and  software. 

In  summary,  there  is  a  great  need  to  verify  that  a  system  design 
is  consistent  with  user  requirements  and  to  prove  the  system  design  has 
the  potential  to  perform  its  intended  functions.  Furthermore,  there 
is  a  need  to  express  or  record  a  design  effort  such  that  it  can  be 
easily  reviewed  and  utilized  for  related  efforts.  More  of  our  current 
research  should  be  directed  toward  these  goals  since  there  is  a  high 
potential  for  a  larger  return  on  the  investment. 

b.  Maintenance.  There  are  two  divergent  ways  to  reduce 
maintenance  cost:  one  way  is  to  make  it  easier  and  less  expensive  to 
do  maintenance  by  designing  equipment  which  will  be  reliable  and  easy 
to  maintain;  the  other  way  is  to  eliminate  the  need  for  maintenance. 
Unfortunately,  it  is  not  realistic  to  eliminate  all  maintenance. 

Even  if  it  were,  the  capability  is  still  needed  to  upgrade  and  meet 
the  changing  needs  of  a  system.  These  same  capabilities  enhance  the 
ability  to  perform  maintenance.  For  example,  detailed  design  and 
coding  standards  must  have  been  established  and  then  followed  for 
effective  maintenance  and  updates.  Furthermore,  it  is  predicted 
that  the  maintenance  cost  on  real-time  systems  currently  under 
development  will  exceed  several  times  their  development  cost  on 
existing  systems  (see  Figure  6-3).  Figure  6-2  shows  that  more 
than  half  of  our  maintenance  is  a  reflection  of  poor  or  incorrect 
design. 

The  management  process  which  is  used  to  maintain  a  program  after 
completion  of  design  is  called  "software  configuration  management" 

[21].  After  configuration  control  takes  effect,  all  code  and 
documentation  forms  should  be  accompanied  with  the  supervisor's 
approval  and  the  reason  for  change.  The  maintenance  programmer 
and  the  chief  programmer  report  to  different  line  supervisors. 

The  maintenance  programmer  should  have  the  responsibility  to  verify 
that  program  modules  work  according  to  the  speci f ications .  The 
maintenance  programmer  formally  agrees  that  the  program  modules  are 
properly  documented,  structured  in  design,  easily  readable,  and 
conform  to  all  specified  standards  [21].  The  idea  is  to  enable 
the  individual  whose  future  effort  is  most  affected  by  the  completeness 
of  the  development  to  have  an  opportunity  to  review  and  accept  or 
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reject  the  software  based  on  his  evaluation  of  its  status  [21]. 
Unfortunately,  in  a  government  installation  the  potential  impact 
of  the  development  effort  is  not  likely  to  receive  the  same  level 
of  scrutiny.  However,  the  same  need  exists  to  ensure  that 
maintenance  can  be  performed.  This  approach  will  increase 
development  cost;  however,  it  should  reduce  the  total  life  cycle  cost. 

c.  Computer  Networks.  The  ability  to  communicate  between 
different  computers  extends  the  horizon  for  potential  approaches 
in  software  development.  It  also  increases  the  need  for  compatible 
and  standarized  software.  The  ability  to  electronically  transport 
and  transform  software  into  different  forms  enhances  the  likelihood 
of  developing  software  that  either  is  in  a  portable  state  or  can  be 
transformed  into  a  portable  state.  Software,  unlike  hardware, 
can  be  transmitted  as  electrical  signals  and  can  be  utilized  in 
another  location,  which  leads  to  uninhibited  sharing  of  resources. 

The  sharing  of  software  is  a  tremendous  opportunity  for  reduction 
of  software  cost. 

( 1 )  An  Operating  Environment  for  Sharing  of  Software.  One 
logical  approach  for  the  identification  of  potential  solutions  for 
software  sharing  is  to  first  define  an  environment  that  would  be  the 
most  conducive  for  shared  involvement.  For  example,  if  each  member 
of  different  teams  at  different  physical  locations  used  identical 
computer  equipment,  an  identical  operating  system,  and  the  same 
computer  language,  there  should  be  an  opportunity  to  share  the 
work  load  where  the  efforts  are  similar.  Furthermore,  if  by  chance, 
each  functional  group  at  different  locations  were  assigned  the 
required  work  could  be  divided  among  all  the  different  groups  and 
the  same  result  achieved  in  a  more  efficient  manner.  Now  carry 
this  process  one  step  further  in  an  attempt  to  illustrate  a  need 
for  cooperation;  for  example,  what  if  this  same  task  had  already 
been  satisfactorily  completed  by  one  or  more  of  the  functional 
groups  in  the  system?  Obviously,  the  desired  software  package 
is  in  existence.  What  should  be  done  next?  In  this  environment 
one  might  think  of  the  software  planner  as  an  individual  who 
selects  the  programs  or  program  families  [36,37]  needed  to  build  a 
software  system.  His  task  would  be  analogous  to  the  designer  of  a 
piece  of  equipment  who  intended  to  extend  his  product  line  with  a 
minimum  of  new  parts.  The  designer  would  identify  basic 
requirements  and  partition  them  into  functional  entities  that  could 
be  supported  by  components  already  designed  and  tested. 

Concept  interchangeability  is  very  desirable;  however,  this  is 
not  likely  to  occur  unless  proper  emphasis  and  planning  are  focused 
on  this  issue.'  The  designer  must  also  recognize  that  there  is  an 
economical  advantage  from  utilizing  components  that  are  in  the 
standard  product  line  oj:  other  organizations.  The  opportunities  for 
economical  gains  from  program  families  [37]  are  even  greater  than 
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those  for  interchangeable  parts.  For  example,  a  portion  of  a  software 
system  that  is  already  available  in  the  form  of  functional  modules  is 
practically  free.  There  may  be  some  interface  problems,  but  it  is  a 
tremendous  opportunity  for  cost  saving. 

A  question  one  should  consider  is  why  government  organizations 
are  not  taking  more  advantage  of  this  sharing  opportunity.  Part 
of  the  answer  is  reflected  in  the  organizational  structure  and  the 
level  of  software  awareness  that  exists  within  the  structure.  The 
individual  who  writes  programs  for  a  particular  organization  probably 
has  his  own  set  of  routines  that  he  uses  over  and  over.  He  has 
tested  these  routines,  knows  the  basic  logic,  and  has  confidence  in 
their  reliability.  The  perspective  is  much  different  once  the 
programmer  is  asked  to  use  some  other  programmer's  code.  He 
may  decide  the  logic  is  not  clear  and  the  documentation  is  inadequate. 
In  fact,  the  programmer  may  decide  it  probably  does  not  even  perform 
the  desired  functions.  Management's  lack  of  knowledge  and  awareness 
of  software  issues  has  practically  guaranteed  that  in  many 
organizations  very  limited  consideration  will  be  given  to  the 
generation  of  software  with  a  planned  intent  for  use  in  multiple 
systems. 

Besides  management  issues,  technical  needs  and  concerns  must  be 
addressed.  For  example,  what  information  must  be  made  available  to 
a  potential  user  so  that  he  can  decide  if  the  software  is  useable 
in  its  current  state?  Once  the  potential  for  modification  has  arisen, 
then  the  information  essential  for  a  decision  of  this  magnitude  is 
considerably  greater  than  that  needed  only  to  implement  the  module. 

It  is  possible  that  software  modules  should  be  classified  such  that 
those  most  likely  to  be  utilized  on  a  repeated  basis  would  receive 
special  attention  in  terms  of  documentation.  What  is  needed  is  a 
virtual  language  that  could  be  translated  to  a  state  compatible 
with  any  system  that  had  specific  functional  capabilities.  These 
software  modules  would  still  have  to  be  tested  to  verify  portability 
and  capability. 

Many  questions  need  to  be  answered  to  pursue  a  solution  along 
this  route.  For  example,  what  definable  characteristics  can  aid 
in  the  selection  of  those  modules  which  are  desirable  for  purposes 
of  sharing?  What  information  is  essential  to  determine  the  utility 
of  a  program?  Would  a  virtual  machine  need  to  be  defined  to  clarify 
functional  requirements  needed  to  ensure  proper  mapping?  Is  it 
possible  to  develop  a  "virtual"  language?  Would  the  language  be 
applications  oriented?  How  can  one  retain  information  such  that  a 
user  can  quickly  determine  the  availability  of  software  to  meet 
a  need?  If  the  cost  of  software  is  so  high,  why  isn't  the  software 
that  is  already  completed,  tested,  and  verified  used  on  repeated 
occasions?  Unfortunately,  part  of  the  answer  is  no  one  knows  how 
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to  easily  identify  software  to  meet  a  desired  utility  and  establish 
the  extent  of  its  portability.  The  potential  is  so  great  that  this 
area  of  research  should  receive  additional  attention. 


(2)  Requirements  for  Protocols.  In  order  to  provide 
effective  communications  within  a  computer  network,  provisions 
must  be  made  for  carrying  on  several  transactions  simultaneously 
on  a  single  access  port.  One  solution  is  to  schedule  the  processing 
of  transactions  on  the  basis  of  identifiers  included  within  each 
message  transmitted  [38,  39]-  this  defines  the  network  access  protocol. 

A  network  access  protocol  should  include  means  for  the  following  [39]: 

•  Identifying  destination  of  data  on  a  message-by-message  basis. 

•  Transmitting  interleaved  messages  to  multiple  computers 
and  terminals. 

•  Precluding  the  delivery  of  messages  to  unauthorized  users. 

•  Controlling  the  flow  of  data  into  the  network. 

The  methods  currently  used  for  accessing  data  communications 
are  very  similar  on  different  networks.  There  are  significant 
benefits  to  be  gained  in  adopting  network  access  standards  [38]. 

This  would  enhance  the  likelihood  of  resource  sharing  and  insure 
that  computer  systems  could  communicate  with  each  other. 

d.  Programming  Language  Issue.  Programming  languages  influence 
the  process  of  program  creation  and  the  properties  of  the  final  program. 
The  capability  to  develop  a  computer  program  on  one  machine  and  execute 
it  on  several  other  machines  is  dependent  on  issues  relevant  to  the 
programming  language. 

(1)  High  Order  Language  (HOL).  Using  a  high  order 
language  (HOL)  can  result  in  reduced  cost,  increased  portability, 
and  lower  maintenance  cost.  Several  issues  relating  to  HOL  for 
communications  language  need  additional  investigation,  such  as 
interfacing  with  operating  systems,  real-time  code,  parallel 
processing,  and  assembly  languages.  The  high  order  languages  currently 
available  have  serious  deficiencies  in  these  areas.  It  is  possible 
with  known  technology  to  develop  a  high  order  language  for  communications 
systems  significantly  superior  to  those  currently  available. 

An  example  of  an  early  attempt  to  make  expert  knowledge  of  an 
application  available  to  the  ordinary  user  was  the  development  of  a 
switch  configuration  simulator  language  called  a  "Communi cations 
Computer  Language  (COMTRAN)."  The  purpose  of  the  COMTRAN  system 
was  to  provide  Rome  Air  Development  Center  (RADC)  with  a  connunications- 
oriented  simulator  system  that  would  accept  parameter  statements  in 
a  language  which  was  convenient  for  test  engineers  to  use  and 


produce  programs  that  could  operate  the  stored  program  element  in 
accordance  with  the  requirements  of  the  engineers  [40].  This 
software  was  restrictive  since  it  was  developed  for  a  specific 
computer  system,  the  4651.  system  [40].  The  need  today  is  for  the 
development  of  knowledge  based  systems  that  are  machine  independent. 

e.  Programming  Methodology.  Limited  advances  have  been  made 
in  programming  methods  and  techniques.  Some  of  these  methods  offer 
immediate  means  to  reduce  cost  [21,  25].  They  are  briefly  described 
to  identify  these  proven  approaches. 

(1)  Top-Down  Design.  The  top-down  approach  utilizes  the 
systems  analysis  concept;  the  bottom-up  approach  attempts  to  identify 
software  components  and  to  develop  a  software  package  through 
synthesis.  The  top-down  approach  starts  with  a  statement  of  the 
objective  and  breaks  down  the  requirements  until  simple  components 
can  be  identified.  This  approach  is  helpful  in  defining  functional 
software  components  required  to  meet  the  objective.  Then,  it  is 
appropriate  to  use  a  bottom-up  approach  to  develop  the  functional 
components . 

(2)  Modular  Programming.  Modularity  denotes  the  ability 
to  combine  arbitrary  program  modules  into  larger  modules  without 
knowledge  of  the  construction  of  the  module.  It  is  an  accepted  and 
widely  utilized  concept. 

(3)  Programming  Team  Concept.  The  programming  team  concept 
is  an  approach  developed  to  utilize  skilled  personnel  properly  and  to 
ensure  that  responsibility  and  accountability  for  software  are  shared 
by  team  members.  It  has  been  successfully  used  on  large  software 
development  projects. 

(4)  Structured  Programming.  Structured  programming  is  an 
attempt  to  reflect  the  structure  of  the  design  within  the  source 
statements  of  the  computer  program.  Basic  rules  are  established  and 
followed.  For  example,  structured  code  modules  are  restricted  to  a 
maximum  number  of  lines.  Control  always  enters  a  module  at  the  top 
and  leaves  at  the  bottom.  All  modules  are  referenced  by  name. 
Branching  between  modules  is  restricted;  a  module  either  returns 

to  its  caller  or  moves  sequentially  to  the  next  module. 

f.  Program  Verification.  It  is  impractical  to  test  every  path 
through  a  program  under  all  conditions,  although  there  are  computer 
software  packages  available  which  aid  in  determining  the  extent  of 
such  testing.  Formal  verification  or  proof  of  correctness  is  an 
emerging  discipline,  but  currently  only  relatively  small  programs 
have  been  verified  using  such  techniques.  A  computer  program  is 
considered  correct  if  it  functions  as  intended.  For  example,  if 

a  program  is  developed  to  perform  a  task  described  by  a  flow  chart, 
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then  a  proof  of  correctness  would  guarantee  that  the  program  performs 
the  logic  that  was  outlined  in  the  flow  chart,  or  more  accurately,  as 
it  was  interpreted  by  the  programmer.  Likewise,  if  a  program  is 
developed  from  a  set  of  specifications,  it  is  not  just  the  specification 
which  dictates  what  will  be  proven,  but  the  programmer's  interpretation 
of  the  specifications. 

Current  methods  for  proof  of  correctness  require  the  programmer 
to  develop  appropriate  assertions  to  insert  within  the  code  and/or 
the  data  declarations.  Since  the  proof  of  correctness  is  dependent 
on  the  validity  and  appropriateness  of  the  assertions,  if  the 
assertions  do  not  truly  reflect  the  intent  of  the  proof,  the  proof 
may  not  provide  the  assurances  sought  and  expected.  Consequently, 
research  is  being  performed  which  ol lows  the  programmers  to  use 
assertions  as  part  of  his  program  specif i cation.  The  problems  in 
proof  of  correctness  have  been  simplified  by  a  new  technique  called 
data  abstractions  [41]  which  are  assertions  to  prescribe  the  extent 
to  which  certain  data  may  be  used  within  a  program  or  subroutine. 

Thus,  as  long  as  these  abstractions  are  followed,  and  the  abstractions 
have  been  verified,  the  program  is  correct.  A  compiler  may  be  used 
to  enforce  compliance  with  the  abstraction  [41]. 

Important  considerations  regarding  the  proof  of  correctness  of 
software  are  summarized  in  the  following  statements: 

•  The  proof  of  correctness  cannot  be  based  on  someone's 
interpretation  of  the  specification,  which  is  not  necessarily 
the  intent  of  the  specification.  Specifications  need  to  be 
expressed  in  a  form  that  eliminates  ambiguity.  Additional 
research  is  currently  being  performed  to  achieve  this  capability. 

•  Proof  of  correctness  procedures  must  be  based  on  a  set  of 
assertions  sufficient  to  guarantee  a  proof.  Research  is  being 
conducted  on  interactive  techniques  to  provide  such  a  capability. 

•  The  capability  to  prove  production  size  programs  is  still 

in  an  experimental  state;  furthermore,  there  are  significant 
requirements  within  DoO  in  security  related  areas  such  as 
"BLACKER"  that  are  dependent  on  this  capability.  Researchers 
have  experienced  success  in  proving  programs  as  large  as  one 
thousand  lines.  However,  the  researchers  have  been  allowed 
to  choose  for  verifying  only  functions  which  could  be  programmed 
in  the  subset  of  a  programming  language  deemed  verifiable. 

•  There  is  a  need  to  extend  the  proof  of  correctness  techniques 
to  handle  computer  programs  that  are  executing  in  a  multi¬ 
processor  environment. 
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•  The  proof  of  correctness  capability  can  be  justified  by  the 

fol lowing : 

-  The  need  to  enhance  program  portability  and  reliable  use 
of  program  libraries  by  using  the  compiler  to  ensure  that 
library  programs  and/or  subroutines  are  propprly  used. 

-  The  high  cost  of  maintenance  in  real  time  systems. 

-  The  potential  loss  of  human  life  or  wasteful  expenditures 
that  can  be  a  result  of  errors  in  software  (e.g.,  space 
flights) . 

-  The  need  to  develop  secure  systems  that  include  software 
components . 

The  need  to  prevent  duplication  of  software  efforts. 

In  the  last  2  years  considerable  effort  has  been  devoted  to  the 
development  of  a  language  whose  structure  would  aid  in  the  development 
of  such  a  proof.  The  University  of  Texas  has  developed  such  a  language 
and  a  methodology  and  is  currently  in  the  process  of  developing  a 
compiler  for  the  language.  Similar  research  is  being  performed  by 
Carnegie-Mel Ion  University,  USC  Information  Science  Institute,  MIT, 
and  others. 

Even  though  Dijkstar  has  correctly  and  succinctly  pointed  out 
that  "testing  proves  nothing  about  the  absence  of  errors  only  their 
presence"  [42],  he  does  not  conclude  that  testing  is  an  obsolete 
approach.  There  still  is  a  need  to  design  and  develop  programs 
such  that  testing  can  be  done  effectively  [43],  No  one  has  suggested 
verification  as  a  replacement  for  testing;  however,  one  can  expect 
improvements  in  the  method  and  control  exercised  in  testing.  The 
high  cost  of  software  maintenance  justifies  significant  expenditures 
to  ensure  that  a  program  design  is  implemented  correctly,  and  it 
seems  reasonable  to  anticipate  significant  resuits  within  the  next 
2  to  5  years. 

g.  Program  Documentation.  Proper  documentation  is  an  important 
step  in  reducing  m-  ntenance  cost  and  providing  the  capability  for 
effective  and  efficient  updates.  Program  documentation  is  one  of 
the  most  arduous  tasks  of  the  programmer;  hence,  management  attention 
is  required  to  ensure  that  programs  are  properly  documented.  It 
is  important  that  the  programmers  have  not  only  adequate  assistance 
to  minimize  the  required  effort,  but  they  also  need  encouragement 
and  control  to  ensure  that  the  task  is  completed,  ['ocumentation 
should  not  be  prepared  in  minute  detail  or  in  a  >  ''m  in  which  it 
cannot  be  easily  updated.  It  is  bettf  to  have  less  but  accurate 
documentation  [21].  There  is  a  serious  need  to  p'G-'-'de  documentation 


to  analyze  programs  automatically  to  determine  if  they  meet  the 
requi rements  of  a  orospective  user.  Obviously,  documentation  is 
essential  for  effective  maintenance. 

(1)  Manual  and  Computer  Assisted  Narrative  Documentation. 

The  capability  to  generate  meaningful  narrative  information  which 
supports  program  development  is  an  area  that  needs  more  investigation. 
Some  facilities  have  developed  interactive  software  packages  which 
request  information  considered  essential  for  documentation.  This 
procedure  guides  the  programmer  during  the  documentation  process 

and  makes  the  task  less  laborious.  Since  timeliness  of  documentation 
is  important,  this  procedure  integrated  into  the  coding  cycle  would 
be  beneficial . 

(2)  Program  Librarian  Functions.  A  librarian  is  needed  to 
ensure  proper  procedures  are  followed  for  updates  and  changes.  It 
is  imperative  that  appropriate  documentation  be  provided  for  new 
library  entries  and  changes  in  the  current  programs.  The  librarian 
assures  that  the  program  library  remains  a  useful  and  reliable  entity 
to  the  user.  The  librarian  is  considered  an  essential  member  of  the 
team  in  the  chief  programmer  team  concept. 

h.  Personnel .  The  skill  level  and  learning  ability  needed  to 
develop  and/or  maintain  real-time  software  have  been  greatly  under¬ 
estimated.  It  was  pointed  out  in  a  recent  report  [44]  that  DoD  has 
insufficient  software  expertise  at  all  levels,  and  retention  of 
skilled  software  engineers  is  hampered  by  an  attitude  that  programming 
is  a  job  for  a  low-paid  technician.  In  another  report  [21]  it  was 
noted,  "The  most  important  single  factor  which  determined  the 
different  development  rates  is  the  experience  level  of  the  designing 
programmers  and  supervisors."  The  large  variance  in  the  productivity 
of  individuals  in  the  development  of  software  makes  it  a  critical 
issue.  There  is  an  urgent  need  to  measure  productivity  and 
identify  those  elements  that  are  critical.  The  importance  of 
personnel  in  software  development  is  reflected  in  the  fact  that  70 
of  the  cost  of  software  is  directly  attributed  to  personnel 
cost  [19.  44] . 

Current  studies  show  a  high  correlation  between  an  individual's 
productivity  and  the  reliability  of  the  software  [19,  22],  i.e  ,  more 
productive  individuals  produce  more  reliable  software.  Relevant  past 
experience  is  important.  The  immediate  supervisor  on  a  project  should 
have  programming  experience.  Suitable  training  and  experience  are 
imperative  for  specialized  programming  such  as  that  required  in  the 
development  of  communi cations  systems  software.  The  minimum  amount 
of  exposure  and  training  required  before  programming  personnel  can 
develop  communications  software  is  not  well  understood.  This 
information  would  be  beneficial  in  both  the  selection  of  personnel 
and  the  evaluation  of  a  contractor's  capability  to  perform  a  task. 
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i.  The  Role  of  Management.  Management  is  the  operational  ami 
that  must  take  the  technical  capability  and  focus  it  on  the  problems 
of  software  development.  There  is  need  for  management  involvement  in 
the  fol lowing  [23] . 

•  For  proper  validation  of  requirements  of  a  new  system 

it  is  necessary  to  perform  a  limited  amount  of  preliminary 
design  as  well  as  proper  analysis.  Management  should 
ascertain  that  critical  design  features  that  cannot  be 
modeled  are  actually  built  and  tested  to  ensure  feasibility. 

The  Defense  Systems  Acquisition  Review  Council,  which  is 
required  to  review  any  system  over  $50  million,  is  vague  on 
the  formal  requirements  for  the  validation  phase  of  the 
acquisition  process;  these  requirements  should  be  amplified 
and  extended. 

•  There  is  need  to  increase  the  visibility  and  understanding 
of  major  software  components  bv  putting  them  on  a  par  with 
hardware  components.  This  visibility  should  be  maintained 
at  all  types  of  reviews  and  in  configuration  control  related 
action. 

•  The  abstract  nature  of  software  makes  it  difficult  to  measure 
progress;  hence,  formalizing  the  design  and  implementation 
steps  is  even  more  important.  It  is  also  imDortant  that 

each  milestone  has  associated  with  it  a  deliverable;  otherwise 
it  is  meaningless. 

•  Several  contractors  have  stated  that  a  formal  development 
plan  is  the  most  important  single  management  document  for 
major  software  systems.  It  should  be  required  as  part  of  the 
bid  package  on  full-scale  development  contracts. 

9  The  use  of  proven  engineering  practices  and  disciplined  program 
practices  should  be  specified  in  the  Request  for  Proposals. 
There- is  a  tendency  to  leave  such  requirements  out  because 
they  might  increase  the  cost;  however,  the  minimum  total  life 
cycle  cost  of  the  software  is  the  real  goal  and  these 
techniques  must  surely  be  used  to  meet  such  a  goal. 

t  In  contracting  for  a  major  software  development  it  is  important 
that  the  selected  contractor  has  the  requisite  experience  and 
capability  with  modern  software  tools.  This  is  extremely 
important  consideration  in  the  selection  of  a  contractor. 

•  The  Request  for  Proposal  should  require  the  bidder  to  define 
an  integration  and  test  plan  and  identify  the  supporting 
elements . 
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•  Special  management  attention  is  needed  to  create  sufficient 
priority  to  ensure  that  qualified  persons  throughout  the 
service  organizations  are  assigned  to  key  positions  in  the 
program  management  organization. 

•  It  is  critical  that  a  software  maintenance  [21,  23]  agent 
be  identified  and  consulted  during  the  validation  phase  of 
a  project.  He  should  follow  the  project  from  development 
to  operational  status. 

3.  AN  APPROACH  FOR  THE  REDUCTION  OF  SOFTWARE  COST 

The  need  for  cost  reduction  in  software  development  and 
maintenance  has  led  to  a  recognition  of  the  requirement  for  the 
development  of  an  overall  software  engineering  package  for  cormunication 
software.  Such  a  software  engineering  package  will  be  utilized  during 
all  phases  of  the  life  cycle  of  software  for  communications  systems, 
hence,  enhancing  software  development  and  improving  the  ability  of 
software  to  be  easily  maintained,  updated,  and  transferred  from 
project  to  project  or  computer  to  computer.  Also,  inherent  in  the 
system  is  the  ability  to  ascertain  a  confidence  of  correctness  and 
security  in  the  software  product.  The  purpose  of  this  section  is  to 
outline  elements  of  such  a  software  engineering  package. 


Several  existing  software  engineering  packages  [44,  45,  461 
are  directed  at  goals  similar  or  related  to  a  software  engineering 
package  for  communications  systems.  The  contents  of  a  software 
engineering  package  is  dynamic  and  should  reflect  the  latest  proven 
technology.  One  of  the  objectives  of  the  software  engineering 
package  is  to  be  able  to  update  the  package  and  to  reflect  advances 
in  technology.  Before  examining  some  specific  requirements  of  such 
a  package  it  is  important  to  review  elements  included  in  the  life 
cycle  uf  suftware  (see  section  v I ,  l.b). 

a  software  engineering  package  must  support  the  total  life  cycle 
of  the  software.  An  effective  software  engineering  package  for 
communications  systems  could  have  the  following  components: 

•  A  method  to  identify  essential  requirements  at  a  level  such 
that  hardware/software  tradeoffs  can  be  realistically 
considered  in  long  range  planning  --  a  modeling  of  processes. 

•  A  higher-level  language  that  is  specifically  oriented  toward 
communications  systems  in  order  to  facilitate  economical 
software  development  and  maintenance.  This  is  the 
Communications  Oriented  Language  (COL)  [47], 
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•  A  compiler  to  translate  portable  COL  statements  into 
executable  code. 

•  A  means  to  provide  and  then  verify  or  prove  that 
a  system  meets  the  desired  security  requirements. 

•  An  operating  system  for  communications  systems  (networks)  that 
can  support  COL  programs  at  multiple  levels  of  security  in  an 
environment  that  appears  machine  independent  to  users. 

•  A  method  or  procedure  to  validate  software  to  ensure  that 
it  performs  its  intended  functions. 

•  Based  on  the  prevailing  level  of  technology,  a  set  of  updated 
and  proven  software  tools  to  support  software  design, 
documentation,  validation,  specification,  and  other  activities 
required  in  software  development  and  maintenance. 

•  An  inherent  capability  for  accommodating  changes  required  as 
a  result  of  varying  applications  and/or  development  of  new 
levels  of  technology. 

•  A  set  of  software  engineering  practices  and  guidelines  that 
ensures  intended  requirements  are  met  in  a  consistent  manner. 

■  A  plan  containing  guidelines  for  the  management  of  software 
projects  in  a  network  environment  such  that  proper  control, 
expertise,  and  software  tools  are  utilized.  This  should 
ensure  that  production  and  maintenance  are  economical  and 
that  the  software  is  reliable. 

•  An  on-line  data  management  facility  that  provides  an 
external  capability  to  monitor,  measure,  analyze,' and 
evaluate  a  software  project. 

•  A  model  or  approach  to  estimate  software  cost  in  order 

to  evaluate  different  alternatives.  The  model  should  also 
estimate  the  relative  value  of  different  practices  and  their 
influence  on  software  cost. 

4.  PROGRAMS  FOR  SUPPORT  OF  A  SOFTWARE  ENGINEERING  PACKAGE 

There  are  both  in-house  efforts  and  contractual  arrangements  planned 
and  in  progress  that  support  the  communications  software  engineering 
package.  These  efforts  are  briefly  described  in  the  following  paragraphs 
Figure  6-4  represents  a  dynamic  plan  which  is  our  ultimate  goal. 

a.  Current  and  Prior  Software  Efforts.  The  efforts  related  to 
software  prior  to  FY76  were  focused  primarily  on  defining  a  conmun i cat  ions - 
oriented  language  (COL)  that  could  be  efficiently  utilzed  for  development 
of  communications  software.  Even  though  plans  for  a  more  encompassing 
software  engineering  package  had  been  initiated  earlier,  very  little  effort 
was  expended  toward  this  goal  until  FY76.  The  following  efforts  are  either 
recently  completed  or  in  progress: 
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Figure  6-4.  Research  and  Development  Essential  to  Attain  a  Significant 
Reduction  in  Software  Cost 
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Guidelines  for  Defense  Communications  System  Software  Production 
This  contract  is  intended  to  review  current  guidelines  and  practices 
needed  to  assist  in  the  economical  development  of  communications  software 
The  contractor  is  required  to  identify  elements  within  communications 
systems  that  can  have  an  impact  on  cost  related  to  software. 

§  COL/Compiler  Development.  This  effort  analyzes  the  require¬ 
ment  for  a  COL,  identifies  the  benefits  obtained  from  using  a  COL, 
describes  a  syntax  for  a  COL,  and  outlines  a  complier  organization. 
Furthermore,  this  effort  will  provide  DCEC  sufficient  information 
to  finalize  its  position  on  the  syntax  for  a  COL.  This  was  a 
competitive  award  to  Bolt  Beranek  and  Newman,  Inc.,  in  FY  75,  with 
a  sole  source  extension  in  FY  76/7T. 

•  Higher  Order  Language  Investigation.  The  objective  of 
this  effort  is  to  define  the  capabilities  required  of  a  higher  order 
language  for  producing  application  software  for  the  Unified  Digital 
Switch  and  using  these  requirements  to  develop  a  highly  efficient, 
reliable,  and  easy  to  use  programming  language  for  use  in  developing 
this  software.  This  language  is  being  developed  by  incorporating  all 
necessary  modifications  and  deleting  all  unnecessary  constructs  from 
an  existing  higher  order  language.  This  is  a  contractual  effort  under 
the  cognizance  of  RADC. 

t  Modular  Architecture  Development.  A  modular  interconnection 
architecture  concept  will  be  evaluated  for  use  on  future  signal 
processing  and  switching  equipment.  This  effort  provides  information 
vital  to  architectural  concepts  being  developed  for  IASA  (Integrated 
AUTODIN  System  Architecture),  future  switching  equipment  development, 
and  communications  processor  equipment.  It  is  a  sole  source  contract 
to  Collins  Radio  Corporation  in  FY  76/7T. 

•  A  Communications  Software  Development  Package.  The 
Communications  Software  Development  Package  (CSDP)  provides  a 
software  environment  in  which  the  application  programmer  prepares, 
tests,  validates,  maintains,  and  simultaneously  documents  his 
programs.  Using  the  CSDP,  he  may  call  upon  any  one  of  the  various 
support  software  packages  to  aid  in  the  preparation  of  finalized 
communications  processing  programs.  This  is  a  multiple  year  contractual 
effort  under  the  cognizance  of  RADC. 

•  The  Communications  Switching  Operating  System.  A  study 
will  be  conducted  to  evaluate  current  operating  systems  and  their 
usefulness  in  a  communications  environment.  These  systems  will  be 
categorized  based  on  the  service  functions  they  perform.  This  is  a 
contractual  effort  that  is  under  the  cognizance  of  RADC. 


•  Performance  Evaluation  of  Software  Candidate  Structures. 
Burroughs  Corporation  under  contract  to  DCEC  has  developed  and 
recommended  a  generalized  software  structure  for  executive  systems. 
There  are  some  obvious  benefits  from  such  a  structure;  however, 
the  current  software  structure  is  not  efficient.  There  is  a  need 
to  model  the  software  structure  so  that  bottlenecks  can  be  identified 
and  eliminated.  Ultimately,  the  structure  will  be  redefined. 
Continuation  of  this  effort  is  currently  planned  as  an  in-house 
effort. 
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b.  Long  Range  Plans.  A  long-range  plan  has  been  defined  in  order 
to  reduce  software  costs.  This  plan  contains  six  general  areas  of 
effort: 


(1)  Software  System  Modeling  and  guidelines  for  DCS 
software  production. 

(2)  The  development  of  a  programming  system  which  consists 
of  a  communications  oriented  language  (COL),  a  compiler  for  the  COL, 
and  a  communications  switch  operating  system. 

(3)  A  communications  software  development  package. 

(4)  A  methodology  for  configuration  of  a  modular 
architecture  development  which  includes  consideration  for  software/ 
hardware  tradeoffs  for  language  interfaces. 

(5)  Multilevel  security  design  and  integration  into  the 
Defense  Communications  System. 

(6)  The  consolidation  of  software  engineering  tools  and 
concepts  into  a  single  and  useful  entity,  namely,  an  automated 
software  engineering  package. 

c.  Candidates  for  In-House  or  Contract  Support.  The  six  areas  or 
interest  will  be  supported  by  either  contracts  or  in-house  projects.  Tire 
in-house  projects  are  freguently  extensions  or  complementary  efforts  to 
contractual  results,  and  represent  a  crucial  effort  which  can  be  ret.  with 
internal  resources.  The  candidate  projects,  which  will  be  phased  over 
a  5  year  period,  are  the  following: 

(1)  A  study  of  the  portability  of  Communications  Orionted 
Languages. 

(2)  Development  of  models  for  performance  evaluution  of 
software  candidate  structures  for  executive  systems. 

(3)  The  development  and  installation  of  basic  computer  networks 
to  be  used  for  research  facilities  (END,  ARPANET,  Secure  Communications 
Node) . 

(4)  An  evaluation  of  the  usefulness  oJ  meta  compilers  for 
elimination  of  machine  dependencies  in  languages. 

(5)  A  conceptual  study  to  determine  feasible  approaches 
for  design  and  implementation  of  software  with  multilevel  security 
requi remen ts . 

(6)  The  development  of  an  annotated  bibliography  on 
software  verification  and  certification. 
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(7)  A  review  of  software  standards  currently 
enforced  by  DoD. 

(8)  An  outline  of  essential  requirements  for  a  software 
acquisition  management  plan. 

(9)  A  concepts  paper  on  implementation  of  computer  networks 
for  communications  systems. 

(10)  Recommendations  for  software  standards  to  support 
communications  systems. 

(11)  A  prototype  model  that  represents  the  skeleton  of 
the  needs  for  project  monitoring  and  evaluation  of  software. 

(12)  A  study  to  evaluate  and  recommend  the  proper 
utilization  of  generalized  data  base  management  systems  such  as 
TOTAL  in  the  development,  control,  and  management  of  software  tasks. 

(13)  An  updated  plan  for  reduction  in  software  cost  which 
contains  the  following: 

(a)  Recent  achievements 

(b)  Current  research  efforts 

(c)  Long-range  plans 

(d)  Milestones 

(e)  Essential  resources 

(f)  A  summary  of  other  efforts 

(g)  An  assessment  of  the  likelihood  of  success  and 
the  respective  benefits  of  each  planned  activity. 

(14)  A  definitive  report  on  measurements  that  are  essential 
for  successful  implementation  of  a  software  engineering  package. 

(15)  A  report  that  outlines  current  software/hardware 
tradeoffs  in  communications  systems  and  expectations  based  on 
current  technology. 

(16)  A  field  study  of  problems  currently  encountered 
with  software  maintenance. 

(17)  Specification  for  the  development  of  a  machine- 
aided  analysis  of  communications  specifications. 

(18)  Specifications  for  a  "software  first"  machine. 

(19)  A  OELPHI  Study  to  identify  which  research  areas 
offers  tne  best  opportunities  for  a  reduction  in  software  cost. 
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The  in-house  projects  will  be  reviewed  each  year.  Progress 
will  depend  upon  the  availability  of  personnel. 

5.  COMMENTS  ON  THE  SOFTWARE  PROGRAM 

The  development  of  a  software  engineering  package  is  a 
consolidation  of  many  capabilities  into  a  single  entity  to  ensure 
all  the  necessary  factors  are  considered  in  a  timely  order.  However, 
the  development  of  a  software  engineering  package  does  not  ensure 
it  will  be  utilized.  Furthermore,  the  development  of  some  elements 
such  as  the  cost  models  for  software,  a  plan  for  transfer  of  software 
technology  into  the  field,  a  plan  for  data  collection  to  support 
software  models,  management  aids,  techniques  for  increased  productivity, 
and  a  methodology  for  design  (see  Figure  6-4).  However,  it  is  currently 
planned  to  integrate  these  requirements  into  current  programs. 

It  is  easy  to  identify  specific  examples  and/or  procedures 
that  reflect  OCA  limitations  in  some  of  the  areas  mentioned  in  the 
preceding  paragraph.  For  example,  the  current  approach  for 
estimating  the  cost  of  telecommunications  equipment  does  not 
separate  hardware  and  software  costs.  If  two  identical  switching 
mechanisms  were  used  one  would  expect  to  pay  for  each  piece  of 
hardware;  however,  the  software  for  additional  systems  may  not 
require  any  additional  expenditures  except  for  installation.  Before 
one  can  expect  to  control  cost,  one  must  be  able  to  identify  the 
cost  of  the  operational  components  and  determine  the  incremental 
cost  expected  for  related  or  identical  systems. 

There  are  certain  proven  approaches  for  development  of 
software  that  have  consistently  reduced  the  life  cycle  cost  of 
software.  However,  these  approaches  are  frequently  not  a 
requirement  placed  in  the  S.O.W.  because  the  Government  representative 
has  no  way  to  justify  or  estimate  the  effect  of  a  particular  approach 
on  the  development  cost.  Current  budgeting  practices  do  not  take  into 
consideration  the  impact  of  software  maintenance.  Indirectly,  upon 
project  approval,  there  is  a  commitment  to  maintain  the  system  which 
is  a  greater  expense  than  the  development  cost.  The  ultimate  result 
is  that  proven  technology  is  not  utilized.  Hence,  there  is  a  need 
for  a  method  to  transfer  proven  software  technology  into  the  field. 

Many  experts  [21,  25]  agree  that  maintenance  represents  more 
than  one  half  (it  has  been  estimated  as  high  as  75%)  of  the  li^e  cycle 
cost  of  software.  Furthermore,  since  80%  of  the  maintenance  cost  is 
directly  attributed  to  design  errors  [25],  there  should  be  more 
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emphasis  placed  on  design  methodology.  One  question  that  has  been 
reviewed  on  occasion  is  whether  there  should  be  a  software 
maintenance  center  or  whether  maintenance  should  be  contracted. 
However,  it  is  more  appropriate  to  consider  the  effect  of  a  design/ 
maintenance  center. 

Even  though  70%  of  the  software  cost  is  directly  attributed  to 
personnel  [19,  443,  very  little  has  been  done  to  increase  the 
productivity  of  people  involved  in  the  production  of  software.  How 
much  work  an  individual  should  be  expected  to  complete  in  a  unit  of 
time  needs  to  be  determined  to  evaluate  personnel  and  make  accurate 
cost  estimates.  The  level  of  achievement  of  people  in  software  has 
been  measured  to  vary  as  much  as  26:1.  Undoubtedly,  this  is  a  fertile 
and  potentially  rewarding  area  of  scudy. 

In  summary,  many  of  the  current  efforts  in  software  are  primarily 
directed  at  meeting  specific  requirements.  For  example,  the 
BLACKER  program  requires  the  capability  to  develop  provable  software. 
Hence,  considerable  expenditures  are  being  made  to  achieve  this 
goal.  It  is  much  easier  to  justify  the  expenditure  of  funds  in 
order  to  meet  technical  goals  that  are  essential  for  long  term 
objectives.  It  is  difficult  to  justify  expenditures  that  will 
increase  the  immediate  cost  even  though  the  total  life  cycle  cost 
will  be  significantly  reduced.  Nevertheless,  if  significant 
achievements  are  expected  in  the  reduction  of  software  cost,  there 
must  be  a  willingness  to  pay  more  in  the  near  term  and  wait  for  the 
rewards  in  the  future. 
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VII.  DYNAMIC  STABILITY 


1.  DEFINITION 

The  dynamic  stability  of  a  communications  system  can  be  thought 
of  as  the  resistance  of  a  system  to  unstable  oscillations  brought 
about  by  conceivable  failure  modes.  It  is  a  function  of  both 
transmission  and  switching  subsystems  and  of  the  user  and  control 
elements.  Dynamic  stability  is  addressed  because  it  is  a  direct 
measure  of  the  performance  of  a  communications  system,  this  performance 
being  affected  by  such  failure  modes  as  equipment  faults  and  transmission 
media  outages,  and  the  propagation  of  their  effects.  It  is  these  effects 
which  can  lead  to  unstable  oscillations  within  the  system  thereby 
causing  a  measure  of  instability.  The  mechanisms  for  preventing  dynamic 
instability  encompass  information  flows  between  and  among  these 
subsystems  and  elements  as  was  discussed  in  section  II. 

2.  PROBLEM  HISTORY 

A  simple  problem  is  offered  that  illustrates  both  the  dynamic 
nature  of  the  DCS  and  a  mode  of  instability.  The  block  diagram  of  the 
transmission  subsystem  affected  is  shown  in  Figure  7-1.  The  problem  was 
a  loss  of  the  signal  from  which  timing  was  extracted.  The  signal 
from  the  FDM  to  the  USC-26  group  modem  experienced  severe  degradation 
resulting  in  a  very  low  signal  level  being  used  for  timing  purposes. 

The  group  modem,  unable  to  discern  the  correct  timing  information,  trans¬ 
mitted  a  pseudo-random  pattern  at  a  voice  frequency  corresponding  to 
50  kb/s.  The  resulting  signal  varied  in  frequency  so  that  it  appeared 
to  the  A/D  device  that  a  number  of  different  signaling  tones  were  being 
generated.  The  A/D  device  amplified  the  received  signal  and  clipped 
the  peaks  resulting  in  a  pseudo-digital  bit  stream  input  to  the  FTC-31 
switch.  Because  of  the  frequency  variation  at  the  output  of  the  group 
modem,  the  FTC-31  incorrectly  interpreted  the  data  stream  as  a  number 
of  different  signaling  tones.  However,  these  tones  were  either  not  in 
the  correct  set  of  signaling  tones  or  were  not  of  a  format  discernible 
by  the  switch  as  valid  or  invalid.  As  a  result,  the  FTC-31  sounded  a 
major  alarm  and  by  locking  up  its  matrix,  ceased  operation  completely. 

This  is  a  case  where  a  fault  (the  loss  of  timing  information),  needlessly 
propagated  caused  a  subsystem  to  fault,  resulting  in  system  instability 
which  caused  premature  shutdown  of  the  switch. 

3.  KEY  SYSTEM  ISSUES 

The  key  issues  in  dynamic  stability  are  timing,  synchronization, 
communications  security  equipment,  and  subsystem  fault  isolation/propagation. 
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a.  DCS  Interim  Timing  Subsystem.  The  interim  DCS  timing  subsystem 
will  provide  initial  network  and  station  timing  equipment  and  techniques 
for  all  digital  transmission  and  switching  requirements,  including 
synchronization,  in  the  transitional  period  of  1980-1990.  A  network 
timing  proposed  for  the  interim  DCS  is  to  utilize  station  clocks  located 
at  major  nodes,  and  to  derive  timing  from  transmission  equipment 
at  minor  nodes.  A  major  node  is  defined  to  be  a  node  with  switching 
function,  high  density  transmission  requirements,  or  peculiar  transmission 
media,  e.g.,  troposcatter .  Minor  nodes  have  none  of  the  attributes  of  a 
major  node. 

(1)  Timing  Equipment.  The  timing  source,  while  unspecified, 
may  comprise  of  independent  atomic  clocks,  LORAN-C  receivers  with 
quartz  clocks,  or  other  similar  combination  of  timing  techniques. 

The  performance  of  the  timing  source,  however,  can  be  specified  in  terms 
of  stability.  No  attempt  is  made  to  discipline  clocks  between  nodes. 

The  timing  subsystem,  in  addition  to  the  clock,  will  include  frequency 
synthesizers,  distribution  amplifiers  and  buffers. 

(2)  Timing  Performance  Requirements.  Timing  performance  is 
characterized  by  two  outage  sources,  equipment  failures  and  the  loss 
of  bit  count  integrity  (BCI)  due  to  timing  slips.  Unavailability  of 
equipment  is  determined  in  terms  of  mean  time  between  failures  (MTBF) 
and  mean  time  to  repair  (MTTR)  parameters.  Table  7-1  summarizes  the 
unavailability  calculations  for  the  timing  subsystem  for  the  DCS 
reference  channel  defined  in  reference  [48].  The  higher  level  buffer 
refers  to  buffer  placement  at  the  bit  stream  output  of  the  radio. 

Buffer  placement  at  the  lowest  channel  where  a  synchronous  interface 
appears  is  termed  the  lower  level  buffer. 

Outages  due  to  slips  occur  when  a  buffer  overflows  or  is  depleted. 
Loss  of  bit  and  frame  synchronization  are  other  outages  but  are  not 
included  in  Table  7-1.  The  outage  caused  by  buffer  excursions  is 
characterized  by  the  mean  time  to  timing  slip  (MTTS)  and  mean  time  to 
recover  timing  (MTRT).  Resynchronization  caused  by  this  timing  failure 
can  be  expected  to  be  approximately  0.5  sec  for  non-satellite  circuits 
and  up  to  1.5  sec  for  satellite  circuits.  An  objective  for  MTTS  is 
24  hours  for  the  global  DCS  reference  circuit  [48],  Table  7-II  shows 
the  allocation  of  this  24  hour  MTTS  to  each  of  the  reference  circuit 
sections.  Note  that  the  individual  section  MTTS  values  are  characteris¬ 
tically  larger  than  the  overall  MTTS  value. 

(3)  Buffer  Lengths.  Buffer  lengths  are  calculated  as  a  function 
of  the  total  accumulated  time  difference  between  two  adjacent  clocks, 

the  propagation  delay  variations,  buffer  reset  period,  and  the  bit 
rate  of  the  data  read  into  the  buffer.  Table  7- 1 1 1  displays  the  buffer 
length  requirements,  in  bits,  to  provide  the  MTTS  allocations  in  Table 
7- II.  Any  two  clocks  are  assumed  to  be  at  most  2  parts  in  10^  of  each 
other.  Propagation  delay  variations  are  assumed  for  line  of  sight  and 
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TABLE  7-1.  ALLOCATION  OF  TIMING  SUBSYSTEM  EQUIPMENT  UNAVAILABILITY 


TABLE  7- 1 1 1 .  BUFFER  LENGTH  REQUIREMENTS  FOR 


trc:"' .i  lit  ?tM-  to  ho  It!  nanoseconds  at  30  mile  and  400  nanoseconds 
at  i,i  miles,  respectively.  The  buffer  reset  periods  are  240  hours 
for  the  lower  level  buffer  location  and  1200  hours  for  the  higher  1  e v <"•  1 
location.  Assumed  bit  rates  are  given  in  the  table.  From  the  buffet 
1'MKith  analysis  it  has  been  found  that  the  propagation  delay  variations 
have  negligible  effect  on  the  total  accumulated  time  difference  when 
compared  to  the  clod  time  difference. 


1,4)  Transmission  Subsystem  Timing.  External  timing  will  be 
accepted  at  the  radio  and  all  levels  of  the  multiplex  hierarchy  of 
the  DCS  transmission  subsystem  (i.e.,  DRAMA).  Figure  7-2  shows  the 
transmit  timing  diagram  for  a  major  node.  The  clock  distribution 
points  are  indicated.  Figure  7-3  shows  the  receive  timing  distribution  fen 
DCS  major  nodes.  Again  clock  distribution  points  are  shown.  This 
figure  indicates  synchronizing  buffers  at  the  lower  level,  and  alternate 
buffer  locations  at  the  higher  level,  note  that  in  either  case,  for 
buffer  placement,  data  is  read  into  the  buffer  using  recovered  timing 
from  the  data  stream,  and  written  out  of  the  buffer  under  local 
clock  control. 

For  minor  DCS  nodes.  Figure  7-4  and  7-5  indicate  the  timing 
distribution  for  the  transmit  and  receive  sections  of  the  transmission 
subsystem,  respectively.  On  the  transmit  side  of  the  transmission 
medium  each  equipment  will  use  its  own  internal  time  base.  Exceptions 
to  this  usage  are:  the  key  generator  ( KG-81 )  which  will  accept  timing 
generated  by  the  radio  or  multiplexer  on  its  encrypted  side  and 
furnish  this  time  to  its  subordinate  multiplexer;  the  radio  (being 
synchronous)  which  will  provide  timing  to  subordinate  multiplexers;  and 
the  level  1  multiplexer  which  will  provide  timing  to  synchronous 
equipments  with  which  they  interface  to  clock  data  out  of  the  synchronous 
device.  In  the  receive  direction.  Figure  7-5,  equipment  timing  is 
provided  by  the  timing  derived  in  the  radio. 

(5)  Transmission/Switch  Timing  Interface.  The  transmit  and 
receive  configurations  of  the  timing  interface  between  DCS  transmission 
and  AUTOSEVOCOM  II  elements  are  shown  in  Figures  7-6  and  7-7  respectively 
[49].  The  switch  shown  is  the  AN/TTC-39  specified  for  the  AUTOSEVOCOM  II 
program.  In  the  transmit  configuration,  the  node  clock  supplies  timing 
to  the  switch  and  each  transmission  equipment,  with  the  exception  of  the 
loop  group  multiplexer  (LGM)  and  trunk  group  multiplexer  (TGM),  which 
will  receive  timing  front  the  switch. 

In  the  receive  configuration,  the  node  clock  provides  the  required 
timing  for  nearly  all  of  the  equipment.  Some  equipments  however, 
will  receive  timinq  from  adjacent  equipment  such  as  the  LGM  and 
TGM,  as  shown.  Diphase  and  non-return-to-zero  (NRZ)  timing  extraction 
are  discussed  in  reference  [49]. 


VI 1  -7 


OIGITAL  LEVEL  1  LEVEL? 

SU8MULTIPLEX  PCM  MULTIPLEX  MULTIPLEX 


DSVT  DSVT 


(6)  Timing  Sources.  Network  timing  with  some  reference 
distribution  or  master/slave  configuration  is  considered  to  be  the 
goal  of  the  future  DCS  timing  subsystem.  Candidate  subsystems  have 
been  developed  and  analyzed  in  reference  [16].  They  can  be  applied 
to  both  major  and  minor  nodes. 

In  the  access  area,  switching  will  be  accomplished  by  means  of 
an  access  area  switch.  DCS  plans  indicate  a  DAX  for  this  purpose. 

It  will  require  timing  for  its  functions  and  will  be  required  to 
transmit  timing  to  secure  voice  terminals  homed  on  it.  The  candidate 
solutions  for  achieving  a  viable  backbone  timing  subsystem  extend 
to  the  access  nodes.  In  reference  [15,  16]  alternatives  are  also 
discussed. 

b.  Communications  Security  Equipment.  Dynamic  stability  is 
affected  by  communications  security  equipment  in  a  synchronization 
(sync)  sense.  More  specifically,  the  interaction  of  the  key  generators 
and  multiplexers  in  a  loss  of  sync  phase,  and  any  resulting  destabilizing 
effects,  must  be  determined. 

(1)  Reference  Circuit.  A  simple  reference  circuit  extending 
from  the  user,  through  switching,  and  to  the  radio  in  the  transmission 
subsystem  is  considered  in  Figure  7-8.  The  two-level  multiplex 
hierarchy  common  to  DRAMA  is  shown  as  is  the  third-level  multiplex  as 
part  of  the  digital  radio  subsystem. 

(2)  Synchronization  Model.  Models  for  frame  synchronization, 
advanced  by  Kozuka  [50],  Sekimoto  [51],  and  Benowitz,  et.  al.  [52], 
have  been  studied  to  gain  insight  to  the  frame  resync  problem  in  terms 
of  a  Markov  analysis.  These  models  have  considered  a  193  bit  frame. 

The  specific  Markov  analysis  corresponding  to  the  mentioned  models  is 
given  in  reference  [53].  The  results,  shown  in  Figure  7-9,  demonstrate  the 
validity  of  the  Markov  analysis.  Benowitz 's  model  was  developed  in 

more  detail  to  determine  the  probability  of  a  false  match  in  6 
consecutive  frame  bits  and  the  probability  of  false  resynchronization. 

These  results  are  given  in  Figure  7-10. 

(3)  Multiplex  Hierarchy.  When  the  analysis  of  the  level  1 
multiplex  in  Figure  7-8  was  extended  to  the  upper  levels  of  the  multiplex 
hierarchy,  the  number  of  states  characterizing  the  Markov  model  quickly 
grew  to  the  point  where  computer  simulation  was  not  feasible.  This 

was  true  even  assuming  a  simple  framing  strategy  of  1  bit  for  both 
levels  2  and  3.  The  analysis  was  performed  on  a  reduced  scale  to 
determine  relative  magnitudes  of  resynchronization  times  in  terms  of 
bit  times. 

From  the  preliminary  results  the  model  chosen  for  the  three-level 
multiplex  hierarchy  is  characterized  by  frame  lengths  of  3,  7  and  15 
bits  for  the  first,  second  and  third  levels,  respectively.  A  channel 
error  model  [54]  was  used  to  develop  the  bit  error  statistics.  It 
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Figure  7-8.  Typical  Section  of  Reference  Link  for  Initial  Studies 
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was  also  assumed  that  if  any  level  of  the  multiplex  lost  synchronism, 
so  did  all  levels  below  it.  Framing  information  is  carried  by  a  single 
bit  in  each  of  the  three  levels. 

A  Markov  analysis  was  performed  on  this  reduced  model  to  determine 
reframe  times  as  a  function  of  bit  slip  probabi 1 i ties  at  each  of  the 
three  levels.  The  results  are  given  in  Tables  7- IV  to  7- V I  in  terms  of 
bits.  Knowing  the  bit  rates  at  the  various  levels  of  the  multiplex 
therefore  gives  the  times  fn  reacquire  synchronism. 

c.  Fault  Propagation/ Isolation.  The  dynamic  stability  of  a 
communications  network  is  an  explicit  function  of  the  fault  modes  that 
can  occur.  Failure  to  stem  tfa  propagation  of  a  faultican  lead  to 
system  instability,  as  was  previously  indicated.  The  subsystems  to 
be  considered  are  identified,  and  failure  modes  and  suggested  actions 
are  discussed. 

(1)  Reference  Link.  The  reference  link  to  be  used  was  shown 
in  Figure  7-8.  It  indicates  the  signal  flows  from  a  subscriber  through 
a  switch  and  transmission  subsystems. 

(2)  Transmission.  The  transmission  subsystem  is  assumed  to 
be  that  described  for  the  DRAMA  proqram.  Satellite  transmission 
facilities  will  be  factored  into  the  reference  circuit  in  future 
efforts,  but  are  neglected  now. 

(3)  Switching.  A  generic  diagram  of  the  switch  is  given  in 
Figure  7-11.  It  is  a  functional  block  diagram  for  an  all-digital 
circuit  switch.  The  line  formatter  provides  the  interface  with  the 
full-duplex  (4  wire)  subscriber  loops  including  loops  to  DAX's, 
concentrators  and  PBX's.  The  line  formatter  functions  include: 

line  termination,  bit  synchroni zation ,  line  group  multiplexing/ 
demultiplexing,  and  detection  of  seize  and  release  supervisory  signals. 

The  trunk  formatter  provides  the  digital  interface  between  the 
switch  matrix  and  incoming  and  outgoing  internodal  trunk  groups.  The 
major  functions  of  the  trunk  formatter  are:  trunk  group  termination, 
bit  alignment,  trunk  group  frame  alignment,  synchronization  buffering 
to  account  for  nodal  clock  differences,  and  extraction  or  insertion 
of  signaling  and  supervision  data  into  a  common  channel  (common  channel 
signaling,  CCS,  assumed). 

The  controller  interface  provides  the  controller  with  signaling 
and  supervisory  data  from  incoming  lines  and  trunk  groups,  and 
generates  such  data  via  controller  action  for  application  to  outgoing 
lines  and  trunk  groups.  The  controller  logic  also  provides  the  common 
logic  for  applying  connection  commands  to  the  switch  matrix. 
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TABLE  7- 1 V .  MULTIPLEX  RESYNCHRONIZATION  AS  A  FUNCTION 


TABLE  7-V.  MULTIPLEX  resynchronization  as  a  function 


TA8LE  7 - V I .  MULTIPLEX  RESYNCHRONIZATION  AS  A  FUNCTION 


Controller 


VI 1-22 


gure  7-11.  Time  Division  Switch  Reference  Model 


The  cc.  troller  is  a  real-time,  stored  program  processor  designed 
for  switching  applications.  The  switch  matrix  accomplishes  intra  and 
inter-highway  time  slot  interchange  in  response  to  connection  commands 
received  from  the  controller.  The  memory  is  provided  for  on-line 
programs,  storage  and  tables  including  connectivity,  routing,  call 
progress  and  conference. 

(4)  User  Subsystem.  The  DCS  user  population  will  utilize 
analog  and  digital  voice  and  data  in  both  clear  and  secure  modes. 

The  clear  analog  subscribers  can  access  the  digital  system  by  either  a 
PBX  or  a  4-wire  connection.  Clear  data  can  achieve  access  through 
a  modem/equalizer  arrangement.  Encrypted  voice  will  access  through 
an  access  area  switch,  probably  a  DAX,  or  a  PBX  in  an  enclave  environment, 
or  be  bulk  encrypted.  Secure  data  will  access  the  system  in  the 
form  of  encrypted,  modemed  signals  and  can  be  digitized  by  existing 
A/D  techniques.  Figure  7-12  shows  the  user  location  and  ir  erfaces 
are  identified. 

(5)  Control .  As  mentioned,  the  control  system  can  be  divided 
into  two  parts,  maintenance  and  operational  direction.  The  function 

of  the  maintenance  element  is  to  restore  the  degraded  subsystem 
element's  service  to  normal  levels.  Status  information  consisting  of 
alarm  indications  with  outages  and  degradation  reports  is  used  to 
initiate  appropriate  maintenance  responses.  The  frequency  and 
timeliness  of  the  status  information  depends,  to  a  large  extent,  on 
the  corresponding  response  time  of  the  maintenance  element  which  may 
be  categorized  as  immediate  responses  (e.g.,  by  technical  controllers) 
or  delayed  responses  (e.g.,  actions  resulting  from  reports  generated 
at  a  DCS  nodal  point). 

Operational  direction  has  the  responsibility  to  ensure  timely 
system  responsiveness  to  the  requirements  of  the  DCS  authorized  users. 

The  mission  of  operational  direction  includes  the  implementation  of 
contingency  plans  and  the  optimization  of  the  availability  of 
communications  resources  for  the  use  of  approved  critical  users. 
Operational  direction  involves  network  reconfiguration,  circuit 
allocations,  reallocations,  restoral  and  denials.  These  are  carried 
ot  *■  bv  pxercising  direction  over  various  subordinate  operational  elements 
such  'echnical  control  facilities  and  switching  centers,  by 
a  apDropriate  maintenance  elements,  or  possibly  by  exercising 

dir>\  '<ntrol  of  system  elements.  Operational  direction  utilizes 
information  related  to  major  nodal  equipment  status,  nodal  configuration 
and  data  base,  network  traffic  status,  and  network  performance.  This 
information  provides  the  forcing  function  for  initiating  response 
control  and  direction  over  network  operations. 

d.  Failure  Mode  Identification.  For  the  subsystems  indicated 
certain  failure  modes  are  identified.  A  subsequent  section  will 
consider  the  impact  of  these  mooes  on  the  defined  subsystems. 
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User's  Location 


igure  7-12.  User  Location  and  Interface  Model 


(1)  Transmission.  The  failure  modes  include: 

•  Loss  of  timing  and  sync  (including  any  interruption) 
0  Loss  of  multiplex  function  (any  levels) 

0  Loss  of  crypto,  and  crypto  imbedding 

0  Loss  of  digital  radio 


(2)  Switching.  As  shown  in  Figure  7-11,  several  important 
blocks  exist.  For  example,  the  switch  matrix  or  the  processor 
controller  have  binary  failure  modes;  they  do  not  appear  to  fail  softly. 
The  switch  cannot  operate  without  these  functions.  Other  failure 
modes  include: 


0  Memory  failure  -  inability  to  access  memory 
0  Controller  interface 

0  Line  and  trunk  formatters  -  including  their  subfunction 
0  Clock  and  timing  failure  -  degraded,  and  total  failed  status 

0  Processor  controller  and  switch  matrix  -  as  mentioned 

(3)  User  (Subscriber).  Clear  voice  and  data  analog  access 

area  subscribers  do  not  appear  to  have  failure  modes  that  have  a  major 
impact  on  other  subsystems.  They  also  will  not  be  digitized  at  the  end 
instrument.  High  speed  data  may  be  the  only  exception,  since  it  already 
exists  in  digital  form;  but  it  will  access  the  system  through  a  modem. 
The  failure  modes  occur  for  encrypted  access  traffic  and  pervade  both 
voice  and  data.  The  modes  include: 


0  Encryption  device 
0  Modems 

(4)  Control  System.  The  elements  of  the  controller  subsystem, 
as  mentioned,  are  maintenance  control  and  operational  direction.  The 
failure  modes  include: 


0  Tech  control  at  the  switch 

0  Maintenance  control  at  switch  node  (but  for  transmission  subsystem) 

0  Communication  failures  between  operations  centers 

e.  Fault  Isolation  Examples.  If  a  fault  in  the  system  occurs, 
the  first  question  to  be  asked  is  can  the  fault  be  immediately  isolated? 

If  not,  the  next  question  is  what  is  the  radius  of  propagation;  that 
is,  what  effects  will  fault  propagation  have  on  other  subsystems. 

One  of  the  key  elements  in  any  stability  discussion  is  that  of 
system  timing.  This  element  pervades  not  only  transmission  and 
switching,  but  also  the  user,  if  time  must  be  transferred  to  his 
terminal.  This  element  has  been  treated  in  an  earlier  section,  with 
specific  reference  to  stability,  and  is  therefore  not  discussed 
further  in  this  section. 
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(1)  Synchroni zation.  Consider  that  frame  synchronization 
in  the  multiplex  hierarchy  on  the  receiver  side  of  a  node  is  faulted. 

The  immediate  result  is  a  multiplex  frame  sync  alarm.  However,  any 
encryption  equipments  receiving  information  from  the  affected 
multiplexer  would  be  alarmed.  This  is  not  desired  since  the  encryption 
device  could  be  operating  normally.  If  it  is  alarmed,  a  resynchronization 
of  both  the  multiplexer  and  encryption  device  could  result. 

Consider  that  encryption  equipment  exists  between  a  higher  and  a 
lower  level  multiplex,  as  shown  in  Figure  7-13.  If  the  higher  level 
multiplex  (HLM)  loses  sync  it  is  desirable  to  maintain  the  encryption 
device  (KG)  in  operation  until  the  multiplexer  requires  sync,  or 
determines  that  it  cannot  resync.  However,  the  KG  is  slaved  to  the 
multiplexers  for  sync  information.  Hence,  to  force  the  KG  to  continue 
operation  in  the  event  that  frame  sync  loss  occurs  at  the  higher  level 
may  necessitate  a  control  element  between  the  HLM  and  the  KB.  If 
either  the  HLM  or  the  KG  loses  sync,  the  lower  level  multiplex  (LLM) 
is  affected  because  it  depends  on  correct  decryption  of  the  data  stream 
for  its  sync  code  detection.  Loss  of  sync  at  either  the  HLM  or  KG 
therefore  destroys  the  sync  information  needed  by  the  LLM.  In  addition, 
the  LLM  does  not  know  if  it  is  at  fault  or  the  sync  loss  occurred 
elsewhere.  The  control  element  appears  to  be  the  key  to  this 
problem. 

When  sync  is  lost  at  the  HLM,  the  control  element  must  inhibit  both 
the  KG  and  the  LLM  from  initiating  a  sync  search.  If  this  is  not 
accomplished,  each  of  the  multiplexers  and  the  KG  would  automatical  1 v 
and  independently  initiate  a  resync  procedure.  This  could  result 
a  resync  oscillation  since  the  operation  of  both  the  KG  and  the  LL*' 
depends  explicitly  on  the  HLM  being  in  sync.  Operation  of  the  LLM 
requires  that  the  HLM  and  the  KG  be  in  sync.  If  the  KG  loses  sync, 
but  the  HLM  does  not,  the  control  element  inhibits  the  LLM  from  initiating 
a  sync  search,  since  this  multiplexer  again  detects  its  sync  from  the 
decrypted  stream.  Resynchronization  therefore,  is  initiated  /  the  KG, 
not  by  the  LLM.  Once  crypto  resync  is  established,  given  tint  the 
HLM  is  in  sync  and  that  the  sync  information  required  by  the  LLM  has  not 
been  corrupted  in  the  transmission  medium,  the  LLM  shou1  '  be  immediately 
in  sync  requiring  no  resync  procedure.  Figure  7-14  sno*o  a  flow  diagram 
of  frame  or  crypto  synchronism  loss  in  the  transmission  subsystem  or  the 
receive  side  of  a  node. 

Similar  reasoning  would  hold  for  replacing  the  encryption  choice 
with  a  multiplexer  in  a  hierarchical  arrangement,  except  that 
control  functions  would  be  exercised  by  the  multiplexers  rather  than 
through  a  discrete  control  element.  This  control  would  then  inhibit 
automatic  resynchronization  procedures  in  the  lower  levels  of  the 
multiplex  hierarchy  should  a  sync  fault  occur  in  a  higher  level.  Once 
the  resynchronizution  is  accomplished  at  the  higher  level,  all  lower 
level  multiplexers  should  be  immediately  synchroni zed ,  and  therefore. 
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do  not  have  to  initiate  their  own  independent  resync  procedures.  This 
results,  as  in  the  previous  discussions,  because  once  the  higher  level 
multiplex  has  reacquired  sync,  it  performs  the  correct  demultiplexing 
function  resulting  in  correctly  framed  data  streams  to  be  input  to 
the  lower  levels  of  the  hierarchy.  This  presumes  the  sync  information 
governing  the  lower  levels  has  not  been  corrupted  in  the  transmission  medium. 

To  this  point,  discussions  have  centered  on  the  receiver  side 
of  the  transmission  subsystem.  Again  consider  Figure  7-13,  but  now  in 
a  transmit  mode.  If  the  LLM  faults,  neither  the  KG  nor  the  HLM 
operation  is  affected  since  their  operation  is  independent  of  that  of 
the  LLM.  What  could  occur  is  that  the  control  element  could  sense 
the  LLM  failure,  inhibit  the  KG  output  to  the  HLM,  and  maintain  the  KG 
in  operation.  The  HLM  would  operate  normally.  If  the  KG  lost  sync, 
the  HLM  operation  would  be  unaffected.  The  KG  would  be  inhibited 
from  accepting  the  LLM  output.  However,  it  would  not  be  desirable  to 
inhibit  LLM  operation  since  the  KG  fault  would  then  spread  to  the  LLM. 

The  LLM  would  in  essence  accept  its  inputs,  in  a  normal  fashion,  and 
discard  the  multiplexed  output  destined  for  the  affected  KG  until  it 
reacquired  sync.  If  the  HLM  loses  sync,  the  operation  of  the  KG  and 
LLM  remains  unaffected.  However,  the  output  of  the  KG  is  discarded 
until  the  HLM  reacquires  sync.  In  this  manner  then,  the  transmit 
elements  can  be  made  essentially  independent  in  operation.  Figure 
7-15  shows  the  corresponding  flow  diaqram. 

In  the  previous  discussions  it  js  been  assumed  the  KG  can 
resync  using  the  received  data  stream  only,  and  that  no  other  KG 
resynchronization  procedure  need  be  effected.  This  assumption  is  true 
if  the  KG  operates  in  a  key-auto-key  ( KAK )  mode.  However,  if  it 
operates  in  a  mode  such  as  Cipher-text-auto-key  (CTAK)  it  cannot 
resync  using  the  data  stream  information  only.  In  such  a  case,  the  KG 
must  effect  resynchronization  by  communicating  with  its  mate,  since  key 
generators  are  paired,  at  the  other  end  of  the  transmission  pipe. 

Operating  in  such  a  mode,  therefore,  necessitates  a  crypto  pair 
resync  if  either  the  KG  or  the  HLM  loses  sync.  The  KG  would 
remain  unaffected  if  the  LLM  lost  sync. 

In  the  examples  considered  for  frame  and  crypto  sync  loss,  the 
switch  need  not  know  that  a  sync  loss  occurred  unless  the  resync 
operation  fails.  This  is  also  true  for  other  equipment  failure  modes. 

Such  failures  necessitate  maintenance  intervention,  and  the  switch 
must  be  prohibited  from  assigning  traffic  to  the  affected  equipments. 

If  maintenance  cannot  be  effected  within  a  specific  time,  a  signal 
must  be  passed  to  the  technical  control  element  to  institute  a  rerouting 
procedure  in  the  switch.  This  signal  would  not  identify  which 
equipment  faulted,  but  would  indicate  that  rerouting  of  affected  traffic 
is  necessary.  This  rerouting  impacts  dynamic  stability  because  it 
introduces  transients  which  can  affect  switching  in  terms  of  blocking 
and  congestion,  or  transmission  in  terms  of  capacity.  This  particular 
topic  will  be  the  subject  of  future  work. 
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(2)  Maintenance  Activity.  The  loss  of  frame  and  acquisition 
failure,  or  an  equipment  malfunction,  can  cause  unnecessary  maintenance 
and  technical  control  activities  at  both  ends  of  the  affected  transmission 
path.  For  example,  consider  that  the  transmission  medium  experiences 

a  short,  temporary  outage.  Alarms  are  sounded  at  both  ends  of  the 
affected  transmission  path,  indicating  a  fault  exists.  The  problem  is 
tnen  one  of  fault  isolation.  However,  the  cause  of  the  fault  may  not 
be  immediately  known,  A  seriously  degraded  signal  level,  for  example, 
might  be  caused  either  by  the  transmission  media  or  by  a  transmit  radio 
failure.  The  symptoms  could  be  identical.  Rerouting  affected  circuits 
offers  a  solution.  However,  circuit  rerouting  introduces  an  unwanted 
transient  into  the  system,  thereby  impacting  system  stability  In 
addition,  the  fault  may  be  cleared  by  the  time  rerouting  has  Deen 
completed.  Hence,  the  maintenance  activity  and  technical  control 
rerouting  would  be  unnecessary.  This  is  true  for  temporary  outages 
resulting  from  fading  transmission  media.  It  is  not  true  for 
permanent  outages. 

As  another  example  of  the  impact  of  maintenance  activity  on 
system  stability,  consider  that  the  transmission  medium  is  degrading 
the  transmitted  signal.  This  degradation  may  be  only  slightly  below 
tolerance  thresholds;  however  it  results  in  an  increased  bit  error 
rate  environment  but  not  loss  of  communication,  as  in  the  previous 
example.  Alarms  are  sounded  indicating  signal  degradation  with 
possible  loss  of  sync.  The  problem  now  becomes  one  of  determining 
if  the  affected  channels  should  be  logged  out-of-service  and  the 
affected  traffic  rerouted  while  testing  is  initiated.  If  the 
degradation  persists,  such  activity  is  necessary.  If  the  degradation 
does  not,  such  activity  could  propagate  the  fault  condition. 

The  point  to  be  stressed  in  these  maintenance  activity  examples 
is  that  a  temporary  fault  can  cause  unnecessary  activity  and  result 
in  a  propagation  of  the  fault.  The  impact  of  this  activity  is  not 
yet  known,  but  is  the  subject  of  studies  presently  being  conducted. 

(3)  Encryption  Imbedding.  One  important  aspect  of  dynamic 
stability  is  the  propagation  of  faults,  which  results  in  undesired 
oscillations  in  the  system.  Examples  of  these  oscillations  were 
presented  in  the  discussion  of  synchronization  loss  in  a  multiplex 
hierarchy  containing  COMSEC  equipment.  An  important  example  to  be 
discussed  here  is  that  of  COMSEC  equipment  imbedding,  specifically 
that  of  properly  operating  encryption  equipments  becoming  affected  by 
faults  in  either  the  transmission  or  switching  subsystems. 

Figure  7-16  shows  an  example  of  encryption  imbedding  wherein  the 
transmission  subsystem  KG's,  required  for  traffic  security  between  nodes, 
are  imbedded  in  a  path  terminated  by  DSVT’s.  The  KG  pairs  are  indicated 
in  the  figure.  Any  disruption  in  communications  between  any  two  paired 
KG’s  will  not  cause  other  paired  KG's  to  be  affected  This  results 
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because  there  is  no  communication  between  inter-paired  KG's.  That  is, 
each  pair  is  isolated  from  all  other  pairs  by  major  switching  nodes. 

The  pairs  are  not  imbedded. 

The  DSVT  pair,  however,  will  be  affected  by  communi cations 
disruption  anywhere  in  the  path.  They  can  only  resync  after  the 
disruption  has  been  cleared.  Hence,  the  occurrence  of  a  fault  between 
a  KG  pair,  while  isolated,  necessarily  propaqates  to  affect  DSVT 
crypto  synchronism  Occurrence  of  a  fault  at  either  the  DSVT  or  in 
transmission  between  the  DSVT  and  the  switch  to  which  it  is  homed 
will  not  cause  a  fault  propagation  to  any  KG  pairs. 

Also  of  interest  is  an  example  in  which  DCS  subscribers  have  their 
own  encryption  device  (not  DSVT's),  and  are  brought  into  the  network  at 
a  minor  node  through  drop  and  insert  capabilities.  Figure  7-17  illustrates 
tuis  idea.  The  minor  node  subscribers  have  imbedded  encryption  devices 
because  the  KG  pair  is  located  between  nodes.  If  the  KG  pair  loses 
sync,  communications  are  disrupted  between  the  special  subscribers. 

This  can  necessitate  resynchroni ztion  of  the  special  subscribers 
encryption  devices.  Hence,  as  in  the  previous  example,  a  loss  of 
communications  between  paired  KG's  can  result  in  this  fault  being 
necessarily  propagated  to  the  subscriber  level. 

4.  DISCUSSION 

The  problem  of  dynamic  communications  stability  has  been 
developed  by  means  of  examples  which  have  treated  timing  buffer 
stability,  synchronization,  maintenance  activity  and  encryption 
imbedding.  Fault  modes  were  identified  in  relation  to  the  examples 
and  the  effects  of  fault  propagation  were  discussed. 

It  has  been  found  that  for  frame  synchronization  loss,  a  control 
element  could  aid  in  the  minimization  of  sync  loss  propagation  to 
various  levels  in  the  hierarchy,  including  COMSEC  equipments. 

Unnecessary  maintenance  activity,  causing  transients  in  the  system, 
could  result  from  switch  or  transmission  faults.  The  result 
would  be  a  spreading  of  the  fault.  Encryption  imbedding  can  cause 
a  fault  propagation  that  is  unavoidable. 

Studies  are  presently  being  conducted  to  determine  analytically 
the  net  effect  of  fault  propagation  on  system  performance,  the 
character  of  the  oscillations  set  up  by  failure  mode  propagations, 
and  the  system  response. 
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VIII.  SUMMARY  CONCLUSIONS 


1 .  GENERAL 

Six  system-level  issues  have  been  defined,  described,  discussed, 
and  analyzed.  These  issues  do  not  represent  the  full  range  of  issues 
which  will  require  resolution  during  the  process  of  moving  toward  DCS  II 
however,  this  effort  represents  another  step  in  interfacing  and 
integrating  the  various  subsystems  and  elements.  The  issues  addressed 
in  this  report  are  those  perceived  as  most  critical  at  the  present  stage 
of  DCS  evolution. 

As  the  programs  and  projects  associated  with  DCS  II  advance  into 
the  implementation  phase,  then  on  to  operational  status,  it  is 
inevitable  that  additional  technical  details  will  become  known  thereby 
surfacing  a  greater  number  of  issues  for  resolution. 

2.  SUBSYSTEM  INTERFACES  -  INFORMATION  EXCHANGE  AMONG  MAJOR  DCS 
SUBSYSTEMS  AND  ELEMENTS 

The  information  needs  of  major  DCS  subsystems  and  elements  have 
been  identified  and  tabulated  via  13  information  exchange  fables. 
Specific  examples  are  presented;  however,  the  tabulation  is  not  intended 
to  be  complete  or  exhaustive.  The  tables  demonstrate  the  type  of 
information  interchange  that  should  be  considered  for  near-term 
project  implementation  as  well  as  long-term  program  objectives.  The 
following  future  actions  are  required: 

•  Detailed  review  of  the  information  tables  and  data. flow  by 
headquarters  DCA  and  the  appropriate  engineering  offices  of 
the  military  departments. 

•  Initiate  a  specification  control  process  to  ensure  that 
future  DCS  subsystems  and  elements  exchange  information  as 
conceptual i zed. 

•  Propose  specification  changes  to  the  hardware  and  software 
for  on-going  developments  or  procurements,  particularly  with 
respect  to  DRAMA,  AN/TTC-39,  DAX  and  SYSCON. 

3.  AUTOSEVOCOM  II/DIGITAL  TRANSMISSION  INTERFACE 

This  analysis  considered  three  basic  concepts  from  which 
13  variations  of  alternatives  for  interfacing  the  AN/TTC-39  and 
DRAMA  were  evaluated.  The  results  indicate  that  the  alternatives 
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addressed  under  Concept  II  (i.e.,  alternative  lb  or  2b)  would  be  the 
prudent  near-term  course  of  action  for  DCA,  considering  the  very  real 
possibility  of  implementing  the  Digital  European  Backbone,  Phases  I-IV, 
by  the  early  1980's.  Alternatives  lb  and  2b  are  manual  in  nature, 
similar  to  the  present  arrangement  in  AUTOVON.  On  the  basis  of  cost, 
coupled  with  schedule  risk,  alternative  lb  appears  more  attractive. 

For  the  far-term,  depending  on  the  growth  of  AUTOSEVOCOM  II  traffic. 
Concept  I  and  Concept  III  (i.e.,  automation  of  technical  control 
functions)  should  be  analyzed  further. 

4.  TRANSMISSION  DIGITIZATION  STRATEGY  -  PCM  VS  DM 

Although  the  present  implementation  plans  for  DEB  call  for 
the  utilization  of  64  kb/s  PCM  for  general  voice  channel  use,  certain 
advantages  and  disadvantages  of  delta  modulation  necessitated  an 
evaluation  of  these  two  possible  strategies.  The  results  of  the  study 
indicate  that  the  advantages  of  a  "PCM  only"  strategy  outweigh  the 
advantages  of  a  combined  PCM/DM  strategy  for  the  near-term  (i.e.,  DEB 
implementation).  See  the  calculated  figure  of  merit.  For  the  far-term, 
the  potential  increase  in  channel  capacity  using  a  combined  PCM/DM 
strategy  justifies  further  consideration. 

5.  DCS  ENCRYPTION 

This  analysis  examined  three  alternative  strategies  for  DCS 
encryption:  (1)  end-to-end  encryption,  (2)  bulk  encryption  from  secure 
enclaves,  and  (3)  PBX-to-PBX  encryption  from  secure  enclaves.  The  idea 
of  enclaves  was  advanced  as  a  plausible  solution  to  certain  subscriber 
encryption  requirements. 

The  results  indicate  that  alternatives  (1)  and  (3)  are  attractive 
courses  of  action  and  should  be  considered  for  application  during 
the  evolution  of  AUTOSEVOCOM  II. 

It  is  anticipated  that  DCA  and  NSA  jointly  will  develop  a  program 
for  further  consideration  of  the  two  courses  of  action. 

6.  SOFTWARE  COST  MINIMIZATION 

Software  cost  is  an  area  with  enormous  potential  for  cost  growths 
that  must  be  brought  under  control.  This  study  analyzes  historical 
data  on  major  DoD  system  acquisition  programs  which  experienced  large 
expenditures  in  software. 

On  the  basis  of  the  analysis, various  courses  of  action,  both 
in-house  and  contractual  efforts,  are  being  considered. 
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7. 


DYNAMIC  STABILITY 


Dynamic  stability  is  a  characteristic  of  any  large  switched 
communications  system.  It  can  be  thought  of  as  the  resistance  of 
the  system  to  unstable  oscillations  brought  about  by  conceivable 
failure  modes.  Dynamic  stability  within  the  DCS  was  explored  by 
means  of  examples  which  considered  timing  buffer  stability, 
synchronization,  maintenance  activity  and  encryption  imbedding. 

Fault  modes  were  identified  in  relation  to  the  examples,  and  the 
effects  of  fault  propagation  were  discussed. 

It  has  been  found  that  (1)  a  control  element  could  aid  in 
minimizing  the  effects  of  fault  propagation  within  the  multiplex 
hierarchy,  (2)  switch  or  transmission  faults  causing  transients 
throughout  the  system  may  result  in  unnecessary  maintenance  activity 
and  further  propagation  of  the  fault,  and  (3)  encryption  imbedding 
can  cause  a  fault  propagation  that  is  unavoidable. 

Studies  now  in  progress  to  determine  the  net  effect  of  fault 
propagation  on  system  performance  will  be  continued.  These  studies 
will  be  analytical  as  well  as  specific  equipment  oriented. 
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